Lorsqu'on encode du MP3 en joint stereo, est-ce qu'on obient au final un fichier qui contient exactement la même chose sur les deux canaux ou est-ce qu'il n'y que les passages semblables qui joints et pas forcément tout le fichier ?

Je c plus trop le principe, mais au final, c'est bien du stereo et pas du mono.
Si je me souviens bien, cela encode une seule fois les sons qui sont des 2côtés en même temps, mais bien chaque côté si c'est différent. On gagne ainsi de la place.
 
Pour un bon encodage, il vaut mieux garder le joint jusqu'à un bitrate de 256 minimum, en dessous, laisser le joint stereo améliorera la qualité finale.

toi tu confonds mono avec 2 canaux identiques et le joint stereo qui est :
 
soit D le canal de droite
soit G le canal de gauche
 
en joint stereo on encode A et B tel que:
A = (D + G) / N
B = (D - G) / N
 
avec N une constant non nulle (en général 2 ou racine de 2)
 
tu retrouves D et G très facilement (je le laisse faire le cacul )
 
bref sur le papier le joint stereo ne pert aucune information par rapport à la stéréo
 
après il existe des modes de joint stereo qui perdent l'information de phase...
mais bon ce n'est peut être pas la peine de rentrer dans les détails
 
la gestion du joined stereo est complexe. tu peux l'utiliser avec un codec comme lame, mais il est déconseillé avec d'autres qui le gèrent mal.

De ttes façons, le vqf est largement meilleur que ses concurents pour l'image stéréo (et pour le reste d'ailleurs, mais c'est un avis perso).

avis perso je ne partage pas personnellement

 
+1

 
j'adore sur ton site le "Le VQF (alias TwinVQ) est un format de compression audio (comme l'abominable MP3), opensource, créé par Nippon Telegraph and Telephon Corp. Je l'utilise maintenant depuis cinq ans et l'expérience* m'a montré que c'est le meilleur** format au monde. (...)
"
 

Tu as pas lu la bonne page.

 
je pense aussi.
 
En tt cas, je peux vous dire qu'apres 1 ans d'utilisation intensive du mpc et de monkey audio, j'ai trouvé mon bonheur : le vqf 128 est absolumment transparent : exit les cd, je fais tenir l'intégrale de bach sur une boite de verbatim tout en gatant mes oreilles d'audiophiles.

Voilà, et pour en revenir au sujet du topic.
 
J'ai pris un fichier .wav stéréo, je l'ai encodé avec Lame en Stereo, Joint Stereo et Forced Joint Stereo.
Puis j'ai copié un des deux canaux sur l'autre pour qu'il y ait exactement la même chose sur les deux et j'ai refait les mêmes encodages.
Ils ont tous exactement la même taille à l'octet près.
 
Donc finalement est-ce qu'on est supposé y gagner en taille ou en qualité ?

 
Tu viens de découvrir le principe du CBR. C'est déjà une bonne chose.

Je sais pas si c'est une question idiote ... je me demande:
 
Est-ce que TOUS les lecteurs MP3 savent lire le VBR et le Joint Stereo.

Pour le joint-stéréo : oui.
Pour le VBR, il faut chercher du côté de winamp v.1 pour trouver un player ne supportant pas ce mode d'encodage.

Donc, on peut considérer que les 2 sont aquis ...
 
J'aimerais également savoir, avec Lame, si j'encode en VBR avec un bitrate minimum de 32kbps et un bitrate max de 320kbps (et joint stereo), est-ce que je suis sur d'obtenir une qualité optimale pour le minimum de taille requise ?
 
Sinon, comment devrais-je faire ?
 
(Récement j'encodais mes MP3 en CBR aux alenteour de 192, 224 ...)

 
Non. Le VBR est un mode d'encodage. Un concept. La réalité de l'encodage - et donc sa qualité - dépendent d'autres paramètres. Un bon preset VBR met beaucoup de temps pour être mis en oeuvre. Il ne suffit pas de spécifier les valeurs minimales et maximales pour être assuré contre les erreurs d'appréciation du codec.
Si tu veux utiliser un mode VBR qui t'assure d'une qualité maximale, utilise :  
--alt-preset medium
--alt-preset standard -Z
--alt-preset extreme -Z

Euh ... mais en fait, j'aime bien RazorLame, y'a pas tous ces presets dedans ...

A moins d'être manchot et sans clavier, le problème est vite règlé.

-Z : toggles the scalefac feature on
 
pourquoi ?

 
http://www.hydrogenaudio.org/extra [...] /erhu.flac
Encode cela avec le preset original et sa variante, et tu comprendras.

ok je teste

Quelqu'un connaîtrait par hasard les options qui se cachent derrière les -alt--preset ? Simple curiosité ...
 
Et aussi, j'ai lu dans un forum qu'il valait mieux utiliser Lame 3.92 avec les alt-prestes car ils avaient été faits pour cette version ? Qu'en est-il réellement ... je me dis que ça ne doit pas changer grand chose ... mais j'en sais rien en fait.

 
Le preset n'est pas résumable en des switches. Il fait appel à des fonctions internes, introduites avec les --alt-presets, comblant certaines lacunes des outils pré-existants
 

Non pas 3.92, mais 3.90.2.
Je ne suis pas certain que la qualité obtenue par les presets soit en rien modifiée par ce changement de version. Et si elle l'est, c'est faiblement (j'attends toujours une mention à un passage précis qui illustrerait la dégradation qu'on suppose aux version > 3.91).
 
Si tu veux être tranquille, utilise la 3.90.2, ou plus exactement la 3.90.3, qui est sortie récemment, et apporte un correctif réel (--alt-preset standard, avec 3.90.3 correspond à --alt-preset standard -Z ; -Z corrigeant un défaut qui apparait sur certains passages).
 
Tu trouveras lame 3.90.3 sur rarewares :
http://rarewares.hydrogenaudio.org

Merci.
 
J'hallucine ou je vois bien une option "No gap" dans LameDropXP 1.3.2 ????

Bon je viens de tester avec un sample, et après coupure, compression, décompression, recollage, le sample a perdu 0,082 secondes. Alors qu'avec le Ogg c'est zéro je pense ... c'est sur la bonne voie donc, mais c'est pas encore impec ...
 
Bon, en fait c'est surtout son décodeur qui est gapless ...
Avec celui de WinAmp ou de Foobar c'est moins beau (je parleur bien du diskwriter, pas de la lecture).

Alors ?

Je profite de ce topic pour poser une petite question : j'utilise EAC et LAME pour encoder quelques morceaux en MP3, et pour ce faire, je compresse directement sous EAC. Seulement, j'ai expérimenté l'encodage avec Razorlame et, pour des morceaux identiques, le bitrate varie fortement...
 
D'où ma question : y a-t-il quelque chose qui modifie l'encodage sous EAC ?
 
Merci pour toute réponse

euh, pour résumer, laquelle de c formule offre la meilleure qualité ?
v3.93.1 en extreme
v3.90.3 en extreme -Z
ou une autre ?(en restant en extreme)
 
merci

Moi j'ai testé et c'est très très très très étranges !
En effet, avec le -Z, le résultat est légerement meilleur mais il reste tout de même de gros artefacts (je sais pas si c'est comme ça qu'on dit ). Enfin bref, j'ai testé en Vorbis et AAC pour voir la différence, mais j'ai également encodé avec Lame en CBR 128 ( -b 128 -m j -q 0) et là : plus l'artefact que j'obtenais en --alt-preset standard -Z
 
Bon, j'utilise Lame 3.93.1 avec RazorLame 1.1.5 alors est-ce un bug ou autre ? car c'est pas normal
 
PS : je peux poster les fichiers si ça intéresse qqn...

alors j'ai parlé un peu vite, j'ai prêté mon casque à un pote, je le récupère demain.
et comme demain soir je serais à l'opéra, le test est repoussé à mardi

Et pour le MP3 ? Tu l'as testé sur les mêmes samples ?

Bon, comme de toute façon je suis en train de faire des encodages (que je veux converver impeccablement) en --alt-insane est-ce que j'aurais intérêt à les encoder plutôt en --alt-CBR 320 kbps en Stereo ?

Comment ça Monkey n'est pas lossless?
Qu'est-ce que c'est encore que cette histoire?

 
 
Zut, j'ai dit une connerie, tous les --alt-presets sont en joint stereo. Bon, est-ce que dans ce cas je pourrais obtenir un résultat similaire en CBR 320 Stereo ? (En modifiant certaines autres choses éventuellement ? Lesquelles ?

Tu pourrais utiliser --preset insane -ms, mais le résultat sera moins bon.

(En fait je viens de tester insane et CBR320stereo sur deux morceaux pris au hasard, en les ouvrant après dans SoundForge:
Il semblerait que dans chaque cas le canal droit soit conservé impeccablement tandis que le gauche varie légèrement. Et les canaux gauche des mp3 insane et CBR320stereo sont plus proches l'un de l'autre que de celui du .wav orignal)
(Je ne parle que de la ressemblance de la courbe car je ne sais pas réellement comment interpréter ces données.)
 
Conclusion: ça change pas grand chose ... mais il faudrait que je me rappelle si j'avais un morceau avec des différences sensibles d'un côté et de l'autre pour tester dessus (ou alors je verrai ce que ça donne en créant les différences.  
Quelqu'un aurait un sample particulier à ce sujet ?)

(au fait quelqu'un sait comment utiliser l'option "-no gap" avec dans la ligne de commande, parce que pour l'instant je n'arrive à l'utiliser qu'avec l'interface LameDropXP, je n'arrive elle me fait chaque fois une erreur avec RazorLame par exemple.)

Comme morceaux avec des differences importantes entre gauche et droite, il y a presque tous les morceaux des Beatles.
 
(attention: visualiser un spectrogramme ne donne pas forcément une indication de qualité)

heu humour ?

je n'ai jamais testé monkey ou tout autre codec lossless mais si je devais le faire je procèderais de la façon suivante :
 
je prends un wav, je l'encode, je le décode et je regarde si les checksum des 2 wav sont identiques
 
si oui, c'est sans perte si non, je vérifie quand même si ce n'est pas une histoire de container (tag...) mais si ce n'est pas ça, ce n'est pas du lossless.
(on peut pousser le test sur plusieurs wav, de préférence stéréo et avec de la guitare si tu préfère )
 
autant il est très difficile de trouver un formalisme de test rigoureux et ayant un sens pour les codec avec perte, autant sur du lossless, c'est simple et sans appel.

 
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.