Reprise du message précédent :

 
Représentatif ou pas, les samples sont encodés à l'identique avec tout codec lossless. Il n'y a pas de killer-sample, comme on peut en trouver avec des encodages lossy ; un échantillon non-représentatif est, avec le lossless, un passage qui conduit à des ratios hors-du commun (dégraissage à 99.9% ou à l'inverse à 0.01 %).
 
Si une différence se fait entendre, il faut peut-être porter son attention au décodeur. Car killer-sample ou pas, une comparaison bit-to-bit avec l'orginal sera concluante. Si tu parviens quand même à trouver des différences, fais nous signe. Ce sera à ma connaissance la première occurence d'une faillite d'un codec lossless.

(A propos de l'utilisation du Joint Stereo ou pas, j'ai trouvé ce lien qui suggère de toujours l'utiliser: http://www.modatic.net/audio/stereo_vs_jointstereo.php  
Bon je sais pas que ça vaut ...)

pourquoi n'utilises tu pas les presets de lame qui utilisent avec parcimonie le joint stereo ?
 
car quand la stéréo est faible le joint stereo est préférable
quand elle est forte mieux vaut la stereo
 
l'avantage des presets est l'utilisation du joint stereo uniquement lorsque il est souhaitable de l'utiliser

Ben c'est ce que tout le monde te dit: laisse le mode joint stereo activé par les presets.

au fait Gabriel, que fait le -Z exactement avec lame ?
car semble t'il il est préférable de l'utiliser avec les presets (je n'ai pas encore fait le test)
 
du coup si c'est effectivement préférable, pourquoi ne pas l'inclure au preset ?

-Z changeait le mode de noise shaping via une utilisation plus ou moins fréquente de scalefac_scale.
 
Il est effectivement inclus dans les presets de 3.90.3

dans ou à partir de la 3.90.3 ?
car en ce moment j'utilise la 3.93.1 avec le preset standard

La 3.90.3 a quelques semaines ; la 3.93.1 quelques mois.
 
La branche 3.90.x est celle d'hydrogenaudio. Schématiquement, elle correspond aux codecs approuvés par Dibrom. La série 3.91 et + correspond au déveleppement 'normal' du codec.
 
La 3.90.2 est restée la seule recommandée par le site, pour la simple raison qu'elle fut la seule à être éprouvée en détails. La 3.90.3 ne diffère que par l'ajout par défaut de l'effet -Z aux deux presets VBR, et à la désactivation du switch.

Le jitter est possible dans un environnement PC ? Je veux dire, par transfert IDE ? Je croyais que le phénomène de jitter était propre (du moins perceptible) aux standards de la hi-fi, quelque peu lacunaires en matière de transfert des données numériques  

Je ne vois pas le rapport avec un quelconque phénomène de jitter. Si ce phénomène de jitter existait (je ne confirme pas et ne réfute pas), il serait autant susceptible de se produire avec un wav non compressé qu'avec un compresseur lossless.
 
L'espace de représentation des données (dans certains cas un mode joint stereo) n'a pas non plus d'influence sur les données, si le passage d'un espace à l'autre est exact. D'ailleur un compresseur plus "général" de données est également susceptible de changer d'espace de représentation des données.
 
Le seul cas où un codec lossless puisse produire un résultat différent est l'utilisation sur un ordinateur défiçiant (calculs faux, corruption mémoire,...).

Oui, le jitter va faire que les information numeriques ecrites sur le disque ne sont pas lue de maniere exactes, ou plutot ne sont pas forcement bien interpretees par le lecteur. Il en resulte donc que l'information n'est plus identique bit a bit avec l'original. On sort donc du concept de 'lossless'. Pour la comparaison, on peut en effet imaginer un decodeur temps reel d'un format lossless qui se 'planterais' de temps en temps, et fournirait a la carte son un signal numerique qui n'est plus identique bit a bit avec l'original. Le format du fichier serai lossless, mais l'interpretation non. Je n'ai jamais entendu de pareil cas pour Monkey, mais c'est imaginable.
 
En tout cas, il est evident qu'entre un CD lu dans le lecteur CD-ROM directement relie en analogique a une carte son, et le meme CD rippe en mode secure, encode en Monkey, et lu depuis le HDD, il y aura forcement une difference de rendu. Mais elle n'est en aucun cas imputable au format ou a l'interpreteur Monkey, mais plutot a la difference de lecture (mode 'Audio' standard vs secure), au convertisseurs D->A (CD-ROM vs carte son/processeur), au transit du signal analogique (cable CD-ROM -> carte puis carte -> sortie vs carte -> sortie), sans parler du traitement analogique sur la carte qui est probablement different entre ce qui vient du CD et du convertisseur local.
 
Desole si j'enfonce des portes ouvertes pour la plupart d'entre vous
 
edit : j'ajoute pour repondre a la question initiale de Guru que le jitter en IDE n'existe pas, ou plutot n'est pas 'visible' pour cause de presence de detection d'erreur, comme sur un CD de donnees.

Si on converti de l'espace rgb vers l'espace yuv, alors la seule perte possible est due au possible manque de précision des calculs.
 
La perte peut provenir du fait que l'on quantifie parfois le résultat avec une précision insuffisante (et oui, le résultat d'une telle conversion est un résultat flotant)
 
Il est également possible d'accélerer ces calculs en limitant la précision (la conversion d'espace colorimétriques est assez couteuse en temps processeur)
 
 

Parce qu'on obtient pas un tel résultat. Le changement d'espace ne permet pas de gagner de place à lui seul. Il permet juste d'avoir une autre représentation possible des données, représentation éventuellement susceptible d'obtenir un meilleur taux de compression.
(le passage en mid/side stereo n'est pas une méthode de compression)

alors là je suis impressionné par tant d'almalgame
 
commençons par le jitter :
le jitter est une différence de synchro entre 2 horloges. Lorsque l'on converti en numérique un signal, on utilise un signal d'horloge. Pour que le retour en analogique soit le plus précis possible il faudrait utiliser exactement le même signal d'horloge, avec les même imperfections. Mais ce n'est jamais le cas. c'est pour cela que l'on utilise une horloge la plus précise possible pour numériser et on essaye de créer un autre signal d'horloge, battant à la même fréquence pour la conversion inverse. Le jitter est donc l'erreur induite par la différence entre les 2 signaux d'horloge. ce problème n'aparait que lors de la conversion numérique vers analogique. une conversion numérique vers numérique n'induit pas de jitter : il n'y a pas d'horloge pour ce type de conversion (ou plutot on le fait à la vitesse ou on veut).
 
ensuite la compression lossless :
la compression sans perte fait appel à des bijections.
pour rappel :
Une bijection f entre 2 ensembles E et F est une application qui fait correspondre à chaque élément de E un unique élément de F et inversement.
 
si f existe alors les ensembles E et F contiennt le même nombre d'éléments (qui peut être infini)
card(E) = card(F)
 
(NDLR : en informatique les ensembles sont toujours finis)
 
il n'y a aucune différence d'un point de vue mathématique entre la manipulation d'un fichier son (numérique bien sûr) et tout autre type de fichier (numérique toujours)
 
tout ceci pour dire qu'une comparaision bit à bit est un moyen de vérifier que cet algo est lossless. pour être précis il faudrait tester toutes les valeurs possibles de l'ensemble de départ et vérifier pour chacun que l'on retombe sur la même valeur pour en être sûr mais c'est un peu long...
 
 
la "compressibilité" d'un fichier est donné par son entropie
l'entropie d'un message (un fichier) est la longueure minimale en bits de code nécessaire à décrire completement ce message
un algo lossless est d'autant plus efficace qu'il se rapproche de l'entropie du fichier
 
PS : saviez vous que l'entropie moyenne de la lettre E dans la langue française est de 3.98bits
l'entropie moyenne d'une lettre étant de 4.7 bits (en comptant l'espace mais pas la ponctuation)
 
 
bon je continuerais ce post un peu décousu plus tard, j'ai une réunion

moi j'utilise winABX qui permet ce genre de comparaison entre 2 wav

winabx ou abc/hr
 
Pour cette histoire d'espaces colorimétriques, on peut sans difficultés passer de rbg vers yuv. L'espace yuv est plus large que rgb et inclus l'espace représentable en rbg, donc toute valeur de rgb peut être exprimée en yuv. Le retours ne pose pas de problèmes, vu que l'on a utilisé à l'origine une couleur représentable en rgb.
Si des systemes utilisent yrgb, c'est pour élargir l'espace représentable par rapport à rgb.
 
Mais rgb et yuv ne sont pas des espaces orthogonaux (pas de bijection entre les deux, juste une injection de rgb vers yuv), donc ce n'est pas représentatif du cas mid/side stereo.
Il y a bijection entre les espaces left/right et mid/side, de même qu'il y aurait bijection entre une représentation temporelle (pcm) et une représentation fréquencielle. Il n'y a donc pas de perte possible autre qu'un manque de précision dans les calculs.
 
Monkey est lossless, donc il n'y a pas de discussion possible (autre que relative à un bug ou disfonctionnement de l'ordinateur) sur une éventuelle perte.
Si tu veux, tu peux prendre un document word, lui ajouter une en-tête wav et le compresser avec Monkey audio. À la décompression, en retirant l'en-tête wav, tu retrouveras ton document word. Si il y avait une perte, cela ne fonctionnerait pas. (essaye donc de coder ton document word en mp3)

Ces deux softs ne fonctionnent qu'avec des fichiers .wav. Si tu veux éprouver les performances du décodeur de Winamp, tu peux éventuellement utiliser le Diskwriter (sans activer ni equaliser ni DSP).

Il y a une petite incompréhension entre nous au sujet de l'orthogonalité:
Je ne parlais pas de l'orthogonalité des axes dimentionnels au sein d'un espace, mais de l'orthogonalité entre les espaces. (ce qui soit dit en passant nous éloigne du sujet d'origine)

si il existe une injection permettant de passer de l'espace RGB à l'espace yuv alors il existe un sous espace de yuv tel que cette injection devienne une bijection entre l'espace RGB et ce sous espace. (donc pas de pertes...)
 
Mais le problème dans tous ça est lorsque l'on passe d'un espace infini comme l'est en théorie l'espace RGB a un espace fini tel qu'il est utilisé en informatique avec une précision sur N bits pour chaque composante.

de mémoire on peut démontrer l'orthogonalité de 2 espaces vectoriels en démontrant l'orthogonalité d'une base de chacun

souvenirs souvenirs.... C'est bien loin la prepa