Pour le YP-ST5X (firmware 1.560) que je viens d'acheter :
Réponse courte : 64 kbps
Le Samsung n'était pas mon premier choix. J'avais surtout peur pour le support du ogg. iRiver était aussi critiqué à ce niveau. Pour les autres marques que j'ai pu trouver dans le commerce, aucune critique sur le net, positive ou négative, mais si ça se trouve ce n'est pas mieux.
En fait, ce n'est pas vraiment une question de bitrate minimum. J'aurais bien aimé profiter de l'outil rehuff[1], complètement buggé, mais il est souvent possible de réparer le fichier avec ogg-cut[2]. Malheureusement, il arrive que le lecteur plante ou que le son soit complètement déformé.
- test 1 : encodage à 128 kbps -> ok
- test 2 : encodage à 128 kbps -> rehuff -> plantage du lecteur à une chute du débit
- test 3 : encodage à 64 kbps -> ok
- encodage < 64 kbps : refus de lire
Pourtant, en analysant le débit ('vex -d -pk -pg -s -w' donne suffisamment d'infos), le test 3 atteint des débits plus faibles que le test 2.
Il est très facile de faire planter le lecteur avec certaines options d'oggenc comme --max-bitrate.
Autre cas : le multiplexage
ogg lisible -> multiplexage -> ogm -> démultiplexage -> ogg illisible (plantage)
La piste extraite a pourtant l'air nickel (dixit vex, ogginfo).
Il y aurait aussi des limitations quant à l'utilisation de tags[3] mais je ne peux rien dire car je ne tagge jamais.
[^] # Bitrate minimum ?
Posté par lcld . En réponse au journal Lecteurs MP3 : test du Samsung YP-F1Z. Évalué à 1.
Réponse courte : 64 kbps
Le Samsung n'était pas mon premier choix. J'avais surtout peur pour le support du ogg. iRiver était aussi critiqué à ce niveau. Pour les autres marques que j'ai pu trouver dans le commerce, aucune critique sur le net, positive ou négative, mais si ça se trouve ce n'est pas mieux.
* XiphWiki : http://wiki.xiph.org/index.php/PortablePlayers(...)
* The Yeep support site (+ forum) : http://www.cczclan.com/yp-55.asp(...)
En fait, ce n'est pas vraiment une question de bitrate minimum. J'aurais bien aimé profiter de l'outil rehuff[1], complètement buggé, mais il est souvent possible de réparer le fichier avec ogg-cut[2]. Malheureusement, il arrive que le lecteur plante ou que le son soit complètement déformé.
- test 1 : encodage à 128 kbps -> ok
- test 2 : encodage à 128 kbps -> rehuff -> plantage du lecteur à une chute du débit
- test 3 : encodage à 64 kbps -> ok
- encodage < 64 kbps : refus de lire
Pourtant, en analysant le débit ('vex -d -pk -pg -s -w' donne suffisamment d'infos), le test 3 atteint des débits plus faibles que le test 2.
Il est très facile de faire planter le lecteur avec certaines options d'oggenc comme --max-bitrate.
Autre cas : le multiplexage
ogg lisible -> multiplexage -> ogm -> démultiplexage -> ogg illisible (plantage)
La piste extraite a pourtant l'air nickel (dixit vex, ogginfo).
Il y aurait aussi des limitations quant à l'utilisation de tags[3] mais je ne peux rien dire car je ne tagge jamais.
[1] http://lists.xiph.org/pipermail/vorbis-dev/2002-August/006266.html(...)
patch 1 : http://lists.xiph.org/pipermail/vorbis-dev/2002-August/006287.html(...)
patch 2 : http://lists.xiph.org/pipermail/vorbis-dev/2002-August/006295.html(...)
[2] http://sourceforge.net/projects/ogg-cut/(...)
-> pour essayer de réparer : vex --serial-number -1 -nf -sin in.ogg 0 - out.ogg
[3] http://wiki.xiph.org/index.php/Talk:PortablePlayers#Samsung.27s_Yep(...)