Reprise du message précédent :
Front-end: interface pilotant un autre logiciel. Par exemple RazorLame est un front-end pour Lame.
 
Comment obtenir un vbr pur d'une taille connue et choisie par avance:
encoder avec des paramètres fixes, observer la taille obtenue, réencoder en changeant les paramètres de manière à obtenir la taille voulue.
 
C'est comme ça que fonctionnent les codecs proposant un mode double passe, non?
 
Et bien qu'est-ce qui empeche de réaliser un front-end dédié à cela?
Il suffit d'avoir un soft qui encode, regarde la taille obtenue, et réencode en ajustant les paramètres. De cette manière, on ne pollue pas le codec.
 
 
Si tu veux absolument obtenir une taille fixe avec Vorbis, comment fais-tu?
Tu encodes avec une valeur de -q qui donne habituellement un bitrate avoisinant la taille désirée, tu regardes la taille obtenue, et tu réencodes en ajustant la valeur de -q.
Alors pourquoi ne pas l'automatiser avec un front-end? Ça ne me parait pas bien dur...
 
Pour ce qui est de choisir de manière optimale les tailles de frames, c'est un autre histoire. Cela nécessiterai du code d'analyse qui n'est pas dans l'encodeur actuel.
 
C'est une fonctionnalité, mais non encore implémentée. C'est comme avec le mp3: il n'existe aucun encodeur (à ma connaissance) qui utilise toutes les fonctionnalités prévues par la norme. Mais ça n'empeche pas qu'il existe des encodeur pas trop mauvais.
 
 
ps: sinon, pour info, je ne participe pas au développement de Vorbis, je ne fais que suivre

Ton front-end (maintenant que je sais ce que c'est   ) ferait de la dichotomie là, non ?
Il faut voir si on peut calculer directement le bon q grâce à la première passe, sinon ça devient très chiant.
 
A part ça, tu n'as pas envie de faire partie de la communautée de développeur OGG ?    
 
PS : je confirme qu'il existe des encodeurs mp3 pas trop mauvais    et entre autre grâce à toi  

Au pire il ferait de la dichotomie.
 
Mais je pense qu'il devrait être possible d'obtenir en seulement 2 passes la bonne taille.
 
Sinon, on peut faire un truc pour accélérer: la première passe n'encode que X% du morceau pour gagner du temps.
 
Ca serait du style: j'encode 1 seconde, je skippe 3 secondes, j'encode 1 seconde...
 
Ça devrait suffir pour être représentatif du morceau, et donc être suffisamment exact.
 
Donc si tu as vraiment besoin d'un mode "2 passes", il ne te reste plus qu'à convaincre des développeurs, sachant qu'un frontend est beaucoup plus simple à programmer que d'implémenter un mode "2 passes" dans un codec

Dibrom parlait de la possibilité d'un mode bi-passe grace aux travaux de Naoki Schibatch, et son nspsytune2 (qui en serait au point mort, comme son auteur qui aurait - temporairement ? - jeté l'éponge. Tu en sais plus ?
 
Sinon, un vrai mode bi-passe pourrait être plus fin qu'un simple réencodage, à la manière des courbes d'ajustement des codecs vidéos. Je pense entre autre au XviD, qui parvient à "taper dans le mille" à la deuxième passe, obtenant la taille désirée dès la deuxième passe. Un vrai mode bi-passe pourrait par exemple connaître des possibilité assez fines d'ajustement à la deuxième passe, en imposant au codec par exemple de mettre le paquet sur les passages les plus difficiles sans toucher au reste, ou de toucher à l'ensemble du morceau ou encore de disposer les bits manquants sur les passages dits faciles, et non les plus durs. Ce qu'un simple réencodage en ajustant le -q à la décimale près ne permet nullement de faire.

Bah un mode 2 passe dans un codec audio, a l'instar d'un codec video donnerai le meilleur algo ABR en terme de qualité...
 
Apres faut vraiment s'acharner pour vouloir absolument un pareil mode, etand donné que l'ABR est peu utilisé

le mode -q X
avec X que tu as calculé grâce à la première passe permet de mettre les précieux bits où il faut puisque c'est du VBR et qu'en VBR, un blanc passera en 32kb/s (si -b 32 pour lame) et les passages difficiles s'envoleront à 320kb/s

ca c'est la theorie
parce que t'a beau mettre -m 0 et -M 512 en OGG, l'aggresivité du codec fera qu'il montera trop lentement en bitrate sur les passage vraiment tres critique.
 
personnellement je pense que la solution serais une analyse du fichier source comme le fait un codec DivX par exemple, pour ensuite s'adapté au mieux... --> c'est pas pour demain aussi

ça dépend de la façon qu'à le mode VBR de choisir son bitrate "instantanné"
 
en tout cas, vivement les prochaines versions  

moi de toutes facons j'utilise encore le MP3 pour la musique , l'OGG seulement pour les films
 
bah ouai, c'est bien tout ces format, mais apres faut avoir le hardware pour le relire .

je garde également le mp3 pour la musique
l'OGG est je trouve encore trop jeune.

Pour les débits inférieurs à 150 ko/s (et notamment inférieurs ou égal à 128), je priviligierais l'ogg vorbis sur LAME. Seul --alt-preset standard permet à mes oreilles à LAME de rester dans le coup face à son rival auto-proclamé. Au delà de 160, il y a le mpc --standard qui vers 170 kb/s met tout le monde d'accord. Par KO.

MP3 CBR 320kbps Joint-Stereo voir VBR 0 / Q 0 à ~224-256kbps qui sortent de LAME 3.92 MMX --> Largement suffisant pour moi...
 
Le MPC je vois meme pas la différence (Si peut^^etre qu'il serais plus petit mais diablement moins pratique...)
 

ça tombe bien, je fais du alt preset standard  
 
le mpc vaincra le mp3 par chaos le jour ou sony sortira un balladeur mpc, c'est à dire jamais.
il n'y a pas que la qualité dans la vie, les côtés pratique et portabilité existent aussi.
C'est pour cela que j'attends de voir qui de l'aac ou de l'ogg gagnera (à moins que micro$oft..., oh non pas ça )

 
Actuellement, je n'ai aucun JB hardware. Juste un discman. Il m'est très facile de réaliser des CD-mp3 sur la base de fichiers mpc. Donc le côté pratique est résolu de mon côté. Surtout que la vitesse d'encodage de LAME en --standard est tout sauf pratique...
 
Je lorgne toutefois sur vorbis, qui offre une bonne vitesse, et surtout une qualité surprenante à 80 kb/s. Je peux envisager de constituer un CD/ogg à 80 kb/s, et ce afin de mettre 20 heures sur une galette (plus avec un 90 minutes). Pour la ballade, ca devrait je pense me suffire, compte tenu de la nature de la dégradation de Vorbis, qui me gêne bien moins que celle d'autres codecs. Pour un baladeur à mémoire flash, cela ouvre de nouvelle perspective, qui s'arrêtaient immanquablement à 128 en mp3. Mettre très de 3 heures de musique sur une carte de 128 MO est envisageable...
 
Là encore, un gros JB sur DD en ogg vorbis me serait d'un intérêt réduit : je veux une super qualité sur mon DD, et par voie de conséquence un gros bitrate. Sur mon CD ou ma carte flash, il me faudra un débit nettement moindre. Actuellement, le bitrate peeling de Vorbis ne fonctionne pas du tout (qualitativement, c'est une mauvaise blague). Il me faudrait de toute manière réencoder en ogg, quand bien même mes fichiers seraient en ogg.
Winamp et un plug-in suffisent à transformer mes mpc en Vorbis -q1, assez rapidement du reste. Avec une nouvelle machine, la conversion sera même ultra-rapide (je pourrais dépasser le x10).
 
Bref, utiliser le mpc ne correspond pas pour moi à un sacrifice de l'aspect pratique. Losqu'un iPod Vorbis verra le jour, je serais plus embêté... Mais à présent, la contradicition entre qualité et pratique a trouvé une issue satisfaisante.

Je me doute que pour toi le mpc est la meilleure solution puisque c'est cell que tu as choisi
 
moi je grave des cd que je peux lire dans mon lecteur dvd par exemple, j'ai un balladeur mp3, etc.
 
et je lorgne aussi sur ogg, qui nous mettrait d'accord (quoi que nous le sommes déjà   )

On verra combien de temps mettra iRiver pour intégrer le décodage de vorbis dans les firmware de ses produits. Si un SlimX sera à même de décoder l'ogg dans les prochains temps (voire même les dataplay, puisqu'iRiver est un des premiers à exploiter ce support), je pense que j'en aurai définitivement fini avec le mp3 (sauf encodages de test). Pour les platines DVD/mp3, je les exclu formellement, en raison du gap qui sépare les fichiers entre eux (trop de quatuors, de symphonies, d'opéra... nécessitent un enchaînement continu pour tirer parti du mp3). C'est d'ailleurs ce qui m'a fait renoncer au mp3 au début de cette année.

un opéra : un mp3  

Je me suis amusé à ça...
le plug-in mp3cue devait m'aider, au moins pour un lecture sur PC, à la navigation. D'une part, il faut oublier le VBR pour que mp3cue fonctionne, ensuite, le plug est aux 3/4 buggé.
 
Et les mp3 d'une heure 1/4 (pour un acte), c'est vachement génial lorsqu'on veut zapper les 5 minutes de discussion des Singspiel ou autres genre alternant chant et jeu parlé.

c'est vrai que dans le genre, Der Ring des Nibelungen.mp3 par exemple, c'est un peu long

Y a Licht de Stockhausen qui fait passer le Ring pour un clip musical. 7 opéras, un par jour de la semaine. A côté, Nirvana est autrement plus confortable d'écoute.

il doit y avoir un grand taux de suicide, à la fois dans la salle et dans la fosse.

L'État subventionne les spectacles et les artistes. Et les personnes qui y vont se flattent tellement l'ego en assistant à ce genre de spectacle :-)
 
D'ailleurs, Licht n'est pas achevé. Karlheinz l'a commencé en 1978 je crois, et il doit manquer une ou deux journées. Je connais une journée, Samstag, et c'est moins chiant que du Puccini ou les 3/4 de la production du XIXème siècle. Mais à petite dose quand même

J'ai encodé le fichier dans plusieurs formats WMA9 :
 
http://snipurl.com/media9
 
Par contre je ne savais pas trop quoi choisir entre quality based, biterate VBR (peack) et biterate VBR simple, enfin vous verrez, mais si je devrais tout choisir il y aurrais des dizaines de fichiers different...
 
 
Il vous faudra certainement windows media player 9 pour lire certains de ces fichiers,
enfin c'est au moins un avant gout.

Un test rapide (car je suis à la bourre), montre que wma9 VBR souffre d'un sérieux problème de pré-écho (clairement identifiable). D'autres défaut aussi, surtout le 24 bit. Je réessaierais ce soir pour être au clair.
 
Merci d'avoir mis en ligne les fichiers

C'est quoi ce wma9pro 24 bits? C'est une blague de Microsoft?
Je veux bien que la version pro apporte le multicanaux et le lossless, mais le 24 bits...
La version standard, de même que le mp3, le vorbis, l'aac, (enfin bref, quasiment tous les codecs) n'est pas 16 bits ou 24 bits ou même 32 bits, c'est indépendant de la résolution, vu que c'est codé en flotant et pas en entiers.
 

Gabriel, dans de monde il existe une dimension parallèle  qui s'appelle le marketing. Dans cette dimension le pipeau est roi. Ils ne menttent pas, il déguisent la vérité, c'est tout

à part ça, le 24bits/96KHz veux peut être tout simplement dire qu'il accepte un wav en 24bits/96KHz en entrée

 
avec le WMA 9 (VBR ou non) on peut encoder normalement.
Avec WMA 9 PRO on est obligé d'encoder en 24bit,
le 16 bit n'est possible qu'en 5.1

Euh c'est quoi cette merde ???

moua a écrit a écrit :     avec le WMA 9 (VBR ou non) on peut encoder normalement. Avec WMA 9 PRO on est obligé d'encoder en 24bit, le 16 bit n'est possible qu'en 5.1

comme l'as dit Gabriel ça ne veut rien dire pour le format de sortie, c'est à dire le WMA
tu est sûr que ce n'est pas plutôt pour le format du fichier en entrée ?

 
En entrée j'ai pris le .wav original en 16 bits.
Mais il réencode obligatoirement en 24bits en WMA 9 PRO (sauf pour le 5.1)

Je maintien que le wma9 lossy (pas lossless) ne converti rien en 24bits, parce qu'il s'en fout completement.
Le premier truc qui est fait dans l'encodeur, c'est de passer les échantillons en flotants.
 
C'est aussi valide que de dire que Lame converti le signal en 64bits.

pourquoi lossy et pas lossless ?

Parce que le WMA9 est "Loosy" et le WMA9 Pro aussi dans un certains mode...
 
Tout codec audio "Loosy" est flottant...

es tu sûr de ce que tu avances ?

Ben non, pas tous.
Un truc du genre dpcm n'est en général pas flotant.
 
J'ai dit pas lossless parce que je n'ai aucune idée sur le mode de fonctionnement du wma lossless.

 
Juste un petit up pour ce beau topic
(je suis en train de reclasser mes favorites )

Ca serait pas pour demain et en plus l'encodage commencé la veille serait pour après-demain!

Mei a écrit a écrit :   ca c'est la theorie parce que t'a beau mettre -m 0 et -M 512 en OGG, l'aggresivité du codec fera qu'il montera trop lentement en bitrate sur les passage vraiment tres critique.   personnellement je pense que la solution serais une analyse du fichier source comme le fait un codec DivX par exemple, pour ensuite s'adapté au mieux... --> c'est pas pour demain aussi

Pourquoi Sony? iRiver semble plus dynamique: Sony n' atjrs pas de modele upgradable par fimware!

HAL a écrit a écrit :   ça tombe bien, je fais du alt preset standard     le mpc vaincra le mp3 par chaos le jour ou sony sortira un balladeur mpc, c'est à dire jamais. il n'y a pas que la qualité dans la vie, les côtés pratique et portabilité existent aussi. C'est pour cela que j'attends de voir qui de l'aac ou de l'ogg gagnera (à moins que micro$oft..., oh non pas ça )

L'ogg est bien parti pour l'emporter.