|
|
|
Daniel
Visiteur
|
Date : 27/04/2005 à 09h30
| Citation : | | Il ne reste plus qu'à programmer tout ça... |
J'ajoute qu'il est difficile de décoder le Rice Code en 45 cycles. Ou, plus exactement, d'ajuster la temporisation entre deux échantillons. Cet ajustement varie en fonction de la longueur du code, mais aussi en fonction de la position du code par rapport aux frontières d'octets. Une programmation classique de l'algorithme doit prendre plus d'une centaine de cycles. Il va falloir ressortir toutes les ruses du programmeur en langage machine, et travailler avec des tables. Ou alors programmer le timer à 22050 Hz. C'est un très beau défi 
Pour Fool-DupleX : précision sur le lossless
La méthode consiste à prédire l'échantillon courant à partir des échantillons précédents. Au lieu de stocker un échantillon, on stocke l'écart avec la prédiction. En général c'est une valeur beaucoup plus petite que l'échantillon lui-même.
Cette valeur peut être stockée sur 4 bits. Mais dans ce cas, il y a des risques (minimes) d'overflow. Ce n'est pas arrivé avec l'extrait du Boléro, mais j'ai fait d'autres tests et j'ai eu le problème.
L'écart peut aussi être codé avec le code Rice. Dans ce cas, il n'y a jamais d'overflow, car ce code n'a pas de limite de taille. Donc le lossless absolu est garanti. Et en plus, la compression est deux fois meilleure qu'en 4 bits. C'est donc la solution idéale
Pour la longueur du morceau joué : on est limité par la taille mémoire, car la charge CPU pour le décodage ne laisse aucun temps libre pour lire la disquette. Avec 512K on devrait dépasser largement 1 minute.
Daniel
|
| en haut - en bas |
|
|
|
Fool-DupleX
Visiteur
|
Date : 27/04/2005 à 09h57
Programmer le timer (si c'est au 6846 que tu penses) ne te servira pas a grand chose. il n'existe pas sur MO et sur TO il execute forcement la routine de service qui est en ROM, donc beaucoup de cycles perdus.
Pour le lecteur de disquette, c'est clair qu'il y a un temps mininal pendant lequel le cpu doit piloter le controleur du floppy donc ca ferait des sauts dans le son. Mais ca meriterait quand meme d'etre etudie de plus pret. Sur OS-9, sans meme avoir optimise les sections critiques, on peut formatter une disquette en tache de fond (il y a certes des petits accoups). Il va de soit que dans ce cas, le code pour aller travailler sur la disquette a ete reecrit de fond en comble (en bonne partie par Prehisto, le roi de la disquette sur Thomson  )
Et puis ca laisse quand meme l'option d'avoir beaucoup de bruitages sur une disquette, ce qui peut aussi etre interessant (un jeu par exemple).
Fool
|
| en haut - en bas |
|
|
|
Daniel
Visiteur
|
Date : 27/04/2005 à 10h51
| Citation : | | sur TO il execute forcement la routine de service qui est en ROM |
Mon idée n'était pas d'utiliser les interruptions, mais de tester la valeur du timer dans une boucle de temporisation. La temporisation est différente pour chaque code Rice, et pour chaque position du début du code par rapport à la frontière d'octet. Si le code Rice prend (par exemple) 24 valeurs, il y a 8x24 cas différents pour le calcul de la temporisation. On peut faire une table précalculée des temporisations, mais il est peut-être plus simple de tester le timer. C'est vrai qu'il n'existe pas sur MO, c'est un bon argument contre.
Daniel
|
| en haut - en bas |
|
|
|
Daniel
Visiteur
|
Date : 29/04/2005 à 22h12
Résultat des essais assez mitigé : il semble impossible de décoder le code Rice, faire l'extrapolation linéaire, calculer la temporisation et jouer le son en 45 cycles. Je cherche maintenant des compromis entre le taux de compression et la vitesse de décodage.
Le code Rice est une excellente idée, malheureusement sa longueur variable est un très gros handicap pour un décodage rapide. On peut envisager un compromis : Rice pour les petites valeurs, longueur fixe pour les autres. Je continue les recherches...
Au cours de mes essais, j'ai fait une découverte qui mérite d'être signalée : un morceau à 22050 Hz encodé avec le code Rice et prédiction de degré 1 est moins long que le même morceau à 11025 Hz encodé avec le même procédé. C'est amusant, mais ça s'explique très bien par la mauvaise précision de la prédiction aux fréquences d'échantillonnage très basses.
Daniel
|
| en haut - en bas |
|
|
|
Daniel
Visiteur
|
Date : 02/05/2005 à 08h54
Poursuite des essais :
Finalement le principal problème est le décodage en 45 cycles d'un échantillon compressé. Le codage des différences en longueur variable est très performant pour la réduction de taille du fichier, mais trop long à décoder.
Je m'oriente maintenant vers un codage mixte (3 bits pour les faibles valeurs, 5 bits pour les autres). La compression est moins bonne par rapport au code Rice, mais meilleure que le 4 bits des démos précédentes. Et la propagation d'erreur n'a pas été nécessaire (sur les tests effectués), c'est donc du "lossless".
Je vais coder cette méthode dans les prochains jours et faire une nouvelle démo.
Daniel
|
| en haut - en bas |
|
|
|
Yoann
Visiteur
|
Date : 03/05/2005 à 14h48
J'ai ecoute le Bolero, tres belle qualite, mais assez court pour 210 Ko de fichier ! 
Continue en tout cas, ca fait du bien d'ecouter de belles choses comme ca sur thomson !
|
| en haut - en bas |
|
|
|
Daniel
Visiteur
|
Date : 03/05/2005 à 16h25
| Yoann a écrit : | | tres belle qualite, mais assez court pour 210 Ko de fichier ! |
Le wav original a une longueur de 3 Mo. Il est déjà réduit de plus de 90%
Avec la nouvelle méthode de compression en cours de mise au point, j'espère atteindre 30 secondes avec 200 Ko.
Daniel
|
| en haut - en bas |
|
|
|
Fool-DupleX
Visiteur
|
Date : 26/05/2005 à 10h49
Daniel, j'ai un projet en tete ou je risque d'avoir besoin de ta technique de compression. J'aimerais pouvoir stocker sur une disquette des extraits musicaux de 10 secondes au moins (mais pas plus de 20 secondes), combien puis-je raisonnablement esperer en stocker sur une face (320 Ko) et avec quelle frequence d'echantillonnage ?
Fool
|
| en haut - en bas |
|
|
|
Daniel
Visiteur
|
Date : 27/05/2005 à 07h30
En prenant le taux de compression obtenu pour le Boléro de Ravel dans la démo déjà faite, c'est de l'ordre de 200 Ko pour 20 secondes en 22050 Hz. Avec ma nouvelle méthode ce sera 200 Ko pour 30 secondes (mais le player n'est pas prêt).
Pour la première méthode le taux de compression est constant, quelle que soit la musique à compresser. Mais le lossless n'est pas garanti à 100%. Pour la deuxième, le taux de compression peut varier légèrement, mais il n'y a aucune perte.
Attention à un piège : si on diminue la fréquence d'échantillonnage, par exemple 11025 Hz, on ne diminue pas dans les mêmes proportions la taille du fichier compressé. J'ai trouvé des cas où il était aussi gros.
Daniel
|
| en haut - en bas |
|
|
|
Yoann
Visiteur
|
Date : 27/05/2005 à 07h33
Daniel, petite question pour toi aussi.
Si on prend une frequence pas trop elevee (et pas trop pourri aussi), combiens de cycles ton decodeur prendrait par VBL environ ?
Merci
|
| en haut - en bas |
|
|
|
Daniel
Visiteur
|
Date : 27/05/2005 à 07h53
Le decodage de ma première méthode consomme 30 cycles par échantillon. En 22050 Hz il y a 45 cycles entre 2 échantillons, il reste donc 15 cycles inutilisés. Ou, si tu préfères, la restitution du son prend 2/3 des cycles en 22050 Hz, ou 1/3 des cycles en 11025 Hz. Je te laisse faire le calcul pour une VBL
La deuxième méthode n'est pas encore programmée, mais je sais déjà qu'elle consommera 100% des cycles en 22050 Hz, donc 50% en 11025 Hz.
Daniel
|
| en haut - en bas |
|
|
|
Yoann
Visiteur
|
Date : 27/05/2005 à 07h57
Ca donne quoi en 11Khz niveau clarete du son ? Est-ce que ca "bave" beaucoup ou le son est trop "metalique" ?
|
| en haut - en bas |
|
|
|
Daniel
Visiteur
|
Date : 27/05/2005 à 08h54
Difficile de l'expliquer par écrit. Il faut l'écouter. Tu peux faire des essais sur PC avec CoolEdit. Je n'y trouve rien de métallique, au contraire. Il y a simplement moins d'harmoniques de fréquence élevée. A l'oreille la différence entre 11025 Hz et 22050 Hz est très perceptible, il n'y a aucun doute quand on écoute successivement les deux pour le même morceau.
Daniel
|
| en haut - en bas |
|
|
|
Yoann
Visiteur
|
Date : 27/05/2005 à 10h30
J'aimerais bien faire une petite anim avec de la musique ... je regarderais ca de plus pret, mais j'aurais peut etre besoin de ta routine alors
|
| en haut - en bas |
|
|
|
Daniel
Visiteur
|
Date : 27/05/2005 à 12h00
Pour compléter ma réponse à FoolDuplex :
J'ai abandonné le Rice Code car le temps de décodage ne permet pas le temps réel.
Pour stocker sur disquette, on peut l'utiliser, et décompresser lors de la lecture.
Je n'ai plus les chiffres en tête, mais la compression est meilleure. De l'ordre de 45 secondes pour 200 Ko. A noter que le taux de compression varie beaucoup en fonction de la nature de la musique.
Daniel
|
| en haut - en bas |
|
|
|
jasz
Visiteur
|
Date : 28/05/2005 à 11h29
| daniel a écrit : | | J'ai abandonné le Rice Code car le temps de décodage ne permet pas le temps réel. |
+1
Le principe des automations ne permet pas le temps réel également. La routine reste performante mais trop gourmande pour un thomson. Mais dés que j'aurai un peu plus de temps devant moi, je regarderai d'un peu plus près.
|
| en haut - en bas |
|
|