tous !
J'ai un certain nombre de fichiers mp3 encodes en 192 ou 320kbit, que j'aimerais passer en 128kbit (because plus de place sur mon jukebox mp3 )
Pour l'instant, ce que je fais, c'est decompresser les mp3 en wave, puis les recompresser a l'aide de cdex et lame, mais c'est quand meme bien long... Ya pas un logiciel qui ferait ca automatiquement et plus rapidement?
merci !

foobar2000
dbpoweramp mc
 
d'autres te feront les recommandations d'usage

Et puis t'avais qu'à les encoder directement en 128kbps (au lieu de laisser d'autres faire n'importe quoi).  

 
impeccable !

 
jvais pas me prendre la tete a tout refaire

 
LOL

il doit être super crade le son après tant de manipulation non ?

Si le réencodage est à éviter (sauf nécessités), il ne produit pas non plus des résultats "supers crades" comme tu le crains.

 
honnetement, ca va

 
Ca me rassure alors... comme je vais bientot acheter un jukebox mp3 et que habituellement j'encode mes cds en mpc/mp3@320 je m'étais demandé si je n'allais pas perdre beaucoup en qualité en diminuant le bitrate...
 

 
Ca depend aussi de ton casque et de l'endroit ou tu ecoutes tes mp3 Dans le metro avec un casque d'entree de gamme... pas besoin de 320kbit

voui
c'est pour ça que je veux le diminuer
 
^_^

 
Autre avantage des bas debits : l'autonoime est grandement améliorée, surtout en CBR

Ah tiens, j'ai jamais fait attention a ca !

 
Tang avait fait un test je crois sur l'iRiver
 
Et sur mon Zen NX, dans les causes éventuelles d'une durée faible pour la batterie, ils mettent "écoute de fichiers WMA ou de mp3 encodés à plus de 128kbps", mais j'ai jamais fait de test... (tous mes mp3 dessus sont à 128...)

http://forum.hardware.fr/forum2.ph [...] t=#t548216
 
mp3 128 CBR : 19h03
mp3 fast medium : 17h36 (pourtant bitrate moyen de seulement 115, mais VBR...)
ogg Q4 : 12h20 (!)

Le test de Tang ne permet en rien de déduire qu'un plus haut débit nuise à l'autonomie (et encore moins "nuise grandement" ). D'ailleurs, de ce test on *pourrait* conclure l'inverse, puisqu'à 115 kbps l'autonomie est moindre qu'à 128 (bien entendu, deux modes d'encodages sont également en opposition). On apprend par contre que Vorbis consomme nettement plus de resources au décodage que le mp3 à débit similaire (sur l'iHP du moins).

C'est vrai qu'il manque un test à 192 kbps par exemple
Dans le doute j'ai vérifié sur le manuel de mon balladeur  (Zen NX)

Ils ne parlent pas par contre de VBR/CBR
J'ai pas fait de test, mais il semble donc bien qu'à haut débit la batterie dure moins longtemps

Oui, mais dans quelles proportions ? Tu dis plus haut que "l'autonomie est grandement améliorée" à bas débit, ce qui est possible certes, mais pas certain non plus. Un mp3 ne demande normallement pas plus de resources au décodage à 128 ou 320 kbps. Ce qui peut modifier l'autonomie, c'est surtout la multiplication des accès disques, consécutive au remplissage plus rapide du tampon à haut débit. Et je ne suis pas certain que ce phénomène frappe les baladeurs à mémoire flash, qui ne nécessitent pas de mémoire tampon, et donc d'accès ponctuels aux données.

 
J'en suis pas si sûr que toi

Sur un PC en tout cas, les ressources demandées restent stables.

 
Avec les pcs d'aujourd'hui c'est clair !
 
[mode papy on]
Sur mon P75, la conso CPU était plus importante avec les mp3 en 160kbit qu'avec ceux en 112.
[mode papy off]
 
J'irai jeter un oeil à la doc de mon jukebox

Stable signifie pour moi identique, à peu de chose près. Que ce soit un Athlon 64 à 4 Ghz ou le papyPC à 4 Mhz.
Fait un test précis avec le speedmeter de foobar2000 en veillant à mettre en tampon tes fichiers : les variations sont infimes, et si l'un des fichiers doit passer sur un Pentium 75, l'autre devrait également être lu en temps réel.

C'était avec Winamp à l'époque, je ne l'ai plus, le P75
Enfin c'est l'impression que ça me donnait à l'époque

Pour ce genre de tests, des mesures sont toujours plus pertinentes que des impressions (placebo inside).

Lorsque j'ai dit ca, j'avais souvenir que le test de Tang montrait une grande différence entre haut bitrate-bas bitarte (en fait c'était l'ogg ) donc mea culpa, la différence n'est peut etre pas si grande . Mais en tout cas elle existe sur les balladeurs a disque dur, ne serait-ce qu'à cause des accès disque 1,5 fois plus fréquents en 192 qu'en 128...
Et sur les balladeurs à mémoire flash, vu les petites capacités je pense pas que 320 soit le bitrate le mieux adapté

 
Et avec un fichier ogg on voit une différence?

Je n'ai plus les chiffres en têtes, mais vorbis nécessite environ 50% de temps de décodage supplémentaire (pour un fichier de durée identique).

Tu peux t'aider de ces chiffres, collectés l'an passé, pour calculer une différence:
http://foobar2000.org/foospeed/

Si quand même...

Il m'avait semblé que non. Je confond peut-être VBR et CBR. D'après toi, cette différence est grande ? marginale ? tout juste sensible ou franchement marquée ?

Et comme je compte bien m'acheter l'ihp120... ca m'interesse bien ce que vous dites, histoire de trouver un compromi.

J'ai lancé un petit test, sur une même plage de CD encodée à 128 puis à 320 kbps. J'ai décodé les deux fichiers à la suite, et ce trois fois consécutivement pour me prémunir de variations accidentelles faussant la comparaison.  
 

La différence est donc réelle, mais ne dépasse pas les 10%. Reste à savoir si cette différence est reproduite à l'identique sur un DSP dédié au décodage du mp3.
 
J'ai ensuite décidé d'utiliser le deuxième décodeur disponible avec foobar2000 : MPG123. Les chiffres précédents sont ceux obtenus avec MAD, qui était activé par défaut. Premier constat, la vitesse est nettement plus rapide avec MPG123:
 

La vitesse a donc doublé par rapport à MAD.
Deuxième constat : 30 % de différence entre un encodage à 128 kbps et le même à 320 kbps. Avec cette librairie de décodage, les bas débits nécessitent par conséquent nettement moins de ressources que les plus haut. Mea Culpa à mon tour

Il reste l'énigme du VBR sur les balladeurs IRiver qui consomme plus que le CBR.
Je suspecte un scan de toutes les trames afin de déterminer le bitrate, ce qui pourrait être évité en gérant les headers VBR (et permettrait en plus une lecture gapless)