Reprise du message précédent :
non jviens de voir j'était bien sur standard  c moi qui me plantait , c bizzare dans ce mode la je ripp a environ 0.8x  c peu non ? ( quest ce que c'est en parano )

Tu as fait un Autodetect dans /options/cdrom ?

c vrai  j'avais oublier   jle fais et j'essaye   merci

non ça change rien  c bizare

Tu extrais à cette vitesse, ou s'agit-il d'une extraction + encodage ? Si tu as des mp3 au terme du processus, la vitesse annoncée est normale. Si tu as des waves, je comprends plus trop.

non je ne fait que ripper en wav des cds gravés c tt  et pourtant ça ripp pas vite   ( enfin d'un otre coté avec un ripper a 10x , les cd mal gravé ou un peu rayé passent très très mal )  en tt cas je vais passé des cds originaux en mp3 pour voir ce que ça donne car j'ai pas encore essayé    long vie a ce topic

up  

Beta 4 cette nuit :
 
- Fixed problems with saving profiles  
- Added support for Monkey's APE encoder DLL  
- Warn if lame encoder is initialized with invalid bitrate/sample rate settings (could lead to a divide by zero)  
- Fixed problem with WMA8 Track number tag that was not filled properly  
- Added feature to select local CDDB file type (DOS/Unix text files)  
- Fixed problems regarding Native NT SCSI library setting and ASPI warning message boxes  
- Added feature to digitally play back a CD, so you can listen to the CD even though it is not connected to the sound card.  
- Added MCDI tag to WMA8/MP3 ID3V2 files, so in the Windows Media player can query additional album information (Thanks Sam)  
- Added support for the NTT VQF encoder DLL  
- Patched vorbis DLLs, fixed managed bitrate problem  
- Many improvements to the Analog Recording function.  
- Fixed crash with WinCoded MP3 encoder  
- Better support for MPC encoder (now on the fly encoding is supported)  
- Added option in the External Encoder settings to send optionally a RIFF-WAV header when encoding from stdin  
- Trim leading/trailing spaces when creating a directory.
 
 
http://cdexos.sourceforge.net/
 
Version française :
 
http://www.darkcristal.com/

les alt preset utilisent le mode joint stereo et je trouve ca dommage

ZEeD a écrit a écrit : les alt preset utilisent le mode joint stereo et je trouve ca dommage

  Heu ... dis-nous en plus là ... ?

oui c'est etonnant    
perso au dessus de 192 je mets tjours "stereo"

le joint stereo quand il est utiliser intelligemment est un excellent moyen de gagner des octets. Lame l'utilise à merveille
 
conseil garde le car en stereo perso je te distingue le mp3 de l'original jusqu'en 256kb/s. en joint stereo c'est en 192kb/s
 
rappelle des bases du joint stereo :
 
la stereo c'est 2 canaux
voie A
voie B
bitrate égal pour les 2
 
en joint stereo c'est
voie A+B
voie A-B
plus de bande passante pour A+B

Beaucoup de « newbies » (en fait, des personnes soit intoxiquées par les mauvaises habitudes que la scène Warez propage, soit que le bon sens étouffe au delà des considérations techniques)  s'étonnent que --alt-preset insane (320 kb/s) emploie le joint stereo. En s'imaginant sans doute que l'auteur des commandes cachées derrière les lignes manquait de connaître les connaissances élémentaires concernant l'encodage...
 
En fait, Darin Morrison (Dibrom) qui a assuré l'intégralité du paramétrage des --alt-preset VBR, s'en était expliqué. La vingtaine de plages complexes employées pour l'affinage des preset gagnaient à l'encodage en qualité lorsque le JS était embrayé. Le mode stéréo assure théoriquement une meilleure image spatiale ; or ces défauts théoriques ne semblaient pas détectables. En revanche, l'espace requis pour un encodage séparé des deux canaux portait très clairement atteinte à la qualité d'ensemble, occasionnant par rapport au JS l'apparition d'artefacts, ou l'intensifications des artéfacts que même le JS ne pouvait éviter.
 
L'attitude à adopter est simple : on garde le JS qui semble bénéfique sur le plan des artefacts sans nuire à la spatialité de l'image sonore, plutôt que de flatter le bon sens qui exige qu'à haut débit une stéréo pure s'impose.

Attention, il y a 2 modes joint stereo: IS (intensity stereo) et MS (middle side).
 
Le MS ne change pas l'image spatiale par rapport à la stereo. Seul le IS peut la changer.
 
Franchement il n'y a aucun désavantage à utiliser le MS par rapport à la stéréo, sauf si bien sur il y a des bugs dans l'algo (comme ce fut le cas dans certains codecs FhG)

Au fait, y a-t-il une différence entre l'IS et le mixed stereo, catégorie que l'on retrouve avec l'analyse sous Encspot de fichiers encodés avec Fastenc ?

mixed, il me semble que c'est l'alternance de IS et de MS suivant les passages (un compromis), mais si Gabriel pouvait confirmer

Ca semble plausible en tout cas.

Mixed c'est le fait d'utiliser simultanément IS et MS sur la même frame: MS pour les fréquences basses/moyennes et IS pour les hautes.
 
Sinon presque tous les codecs passent de joint stereo à stereo normale suivant les caractéristiques de la frame courante.
 
Si ils ne changent jamais, on appelle généralement cela le "forced joint stereo" et ça c'est pas très bon.

Sur la même frame ? cela me surprend. Belle perf...
Merci pour les détails.
 
 
PS : y a-t-il encore des développeurs qui chiadent leur Intensity Stereo pour LAME ? Est-ce encore à l'ordre du jour ?

Gabriel, je profite de ta présence pour te poser une question sur lame
 
d'après ma "longue" expérience de lame avec le preset alt en standard, il me semble qu'un peu de bitrate peut être économisé dans les morceaux mono
j'encode en ce moment du jazz et sur la plupart des morceaux en mono que j'ai encodé, le bitrate est fixe à 128kb/s
est il prévu de baisser ce palier en cas de plage mono ?
a mon avis on peut descendre à une moyenne de 110kb/s avec une plage mono sans blanc en utilisant du 96kb/s sur certaines frames
 
ps : merci pour ton explication sur le mixed stereo

--alt-preset standard fixe une valeur plancher de 128 kb/s par frame (sauf -32, pour silence numérique). On peut forcer le preset à descendre plus bas (-b 96 je crois).

oui mais ce qui m'interesserait serait du 96kb/s uniquement sur des frames mono
pour le reste, le plancher de 128 me parait totalement justifié

cool on en apprend plein ds ce topic  

Sortie de la beta7, avec une nouvelle floppée de correction (ils les trouvent où, leur bugs ?) et de petites mises à jour (ogg vorbis, Monkey Audio 3.97...)
Il n'y a plus de raison à encore utiliser l'ancienne 1.40. Bons rips    
 
 
Changes since CDex 1.50 beta 6:
 
 
 

• Fixed Vorbis comment field problem and track number field problem  

• Extended Vorbis quality range from -1.0 to 10.0  

• CDDB proxy authentication was not working properly  

• Fixed drag 'n' drop problems  

• Avoid second file overwrite warnings when ripping to a WAV file

• Fixed bug: CDex could crashed CDDB proxy authentication was enabled  

• On some systems the profile settings were not always updated  

• Added keyboard short-cuts to Audio CD toolbar controls  

• Modified the play audio track (dropped the separate play multi concept)  

• Fixed bug: The settings dialog was (sometimes) displayd incorrect (too large fonts)  

• Fixed missing help IDs (help file was not always opened correctly)  

• Send WAV Header setting in the external encoder option was not persistant  

• Added "%y" tag to external encoder, which is replaced by the year field  

• CD Volume ID (CDPlayer.ini ID) was not calculated correctly for CD < 3 tracks  

• Fixed problem with renaming trackname (first char of every word)  

• Fixed problem with non persistant compression settings of the WAV encoder  

• New buttons and logo, provided by Dustin Halstead (aka: Mangax, mangax@midsouth.net)  

• Upgraded to version 3.97 of the Monkey's APE encoder/decoder libraries  

• Added additional language file

Le format musepack (extension? Je sais plus) n'a RIEN a voir avec le mp3 si ce n'est qu'il s'agit d'un formats de compression audio avec pertes (de type VBR car c'est evidemment l'avenir de la compression audio!) Néanmois le mp3 est un vieux codec alors que musepack est tout nouveau tout beau et offre une qualité nettement supérieure (en haut bitrate!)
 

 
C'est pour moi que tu dis celà ?

Dis donc, ton test mp3 / Slim-X s'est un peu amélioré, mais il reste quelques points contestables, voire risible :  
 
http://julos.girard.free.fr/
 
Test du SlimX par Tang
 
(dédié à la sémillante Aurélie ;-)
 
 
 
J'ai donc moi-même comparé les courbes de fréquences de mon ABR avec du CBR 192kbps (avec Cool Edit version démo) et la comparaison m'a semblé tout à fait concluante... A vous de voir donc mais pour ma part je serais "bon apotre" et j'encoderai désormais en CBR en vertu du principe de précaution!
 
Essaie de tester avec tes oreilles plutôt ; la courbe fréquentielle ne t'apprendra rien, pas en tout cas en ce qui concerne la qualité d'un encodeur perceptuel.
 
...Variable Bit Rate  (...) souvent retenu pour les codecs récents tels le prometteur Ogg Vorbis ou l'exceptionnell MpegPlus - mais pas le génial mp3pro
 
Le mp3pro VBR existe depuis 3 mois
 
Si toutefois vous vous défiez des avantages par trop théoriques du VBR je vous conseille plusieurs solutions CBR
 
Le VBR ne présente pas que des avantages théoriques, mais aussi et surtout (c'est sa raison d'être) perceptifs. On utilise le CBR que par contrainte technique, et non à des fins qualitatives (320 exclu).
 
Mr.Qualité à Codec Blade v1.01 CBR 256kbps Stéreo (ce codec ne permet pas le JS!) : un mp3 de ce type fait un certain poids mais la qualité devrait etre indiscernable de l'original y compris pour les tympans quatre étoiles...
 
Tares du codec Blade :
 
No lowpassing
wrong transcient detection
too late short block switching
bad reservoir handling
no joint stereo
non optimal huffman compression
a lot of bugs everywhere
wrong ath
bad best quantization selection
no scalefactor use
no scfsi
 
L'auteur de la litanie est Gabriel Bouvigne, qui développe avec d'autres LAME et qui fréquente assidument ce forum... Tu peux lui demander quelques précisions à ce sujet. Blade est un codec MacDo, et pas du tout « Quatre Étoiles » !
 
Mr.Qualité/PoidsPressé à Codec GOGO v2.39 (définitive!)
 
La version 3 (3.1) est sortie, et bien avant le Slim-X que tu as testé. Elle est largement meilleure par défaut - plus lente aussi certainement.
 
Et le plus fun :
 
/ !\ Important : A noter que le codec Lame est ASOLUMENT à prescrire aux bitrates 224kbps et 256kbps car des bugs dégradent le son de manière inadmissible et le résultat est plus proche du Real Audio que d'autre chose ;-)!!!
 
D'ailleurs, le Slim-X est plus proche d'un poste radio à galène    
Le manque de logique de cette assertion ne t'a pas dérangé ? Tu n'as pas cherché à la vérifier ? J'aimerais que tu m'envoie un seul échantillon LAME 224-256 qui soit « inadmissiblement » dégradé sans l'être à 192.
Quand on réalise un test, on le fait jusqu'au bout, sans colporter des anneries de « manière indmissible ».
 
 
Il te reste donc encore des choses à corriger (il me semble que tu as déjà réalisé qq retouches depuis deux moins, non ?). Parce qu'avec un tel feu d'artifice, on se sent pas trop en confiance avec la partie technique du test (qui est vraiment complet d'ailleurs, et regorge d'infos : félicitation - sincèrement).

 
 
Euh... le présent, plutôt. Non ?

Mercil'ami pour tes précisions. Mais je dois ajouter quelques trucs importants. A propos de bugs de Lame aux bitrate de 224 et 256 kbps: comme mentionné dans le test il s'agit des données du magasine ANM N°2 à partir des courbes réalisées et non d'écoute!!! Idem pour Blade qui m'a tjrs paru avoir bonne réputation du reste. Sinon si mes codecs sont datés c'est parc'que disposant jusqu'à recemment d'un PC instable (CM A7M + Ge Force 256...) je n'utilisais que la version 1.30 de Cedex (les betas etant jugées moins stables) D'autre part je n'ai pas Internet et je m'aprovisionne logiciellmt via de magasines bouclés avant la fin du mois. A noter que pour le VBR tu me concederas que ce mode n'a été implémenté au mp3 que sur le tard ce qui peut susciter des doutes quand à son adaptation à ce codec pensé initialement pour le CBR... Enfin quand je dis que le VBR est l'avenir de la compressio,n audio c'est parcerque meme si en terme de quelité le mp3 est déjà dépassé il reste LE codec utilisé par la majorité (du fait de la base commune de fichiers et du non support de la plupart de news formats par les baladeurs) et si tu regardes la part du VBR MP3 sur le net lle est minime. C'est en ce sens que le VBR est l'avenir et non le p^résent.  
Sinon merci pour l'info sur le mp3pro VBR je l'ignorais meme si la structure du Codec  (mp3+ pro) rendait evidemment cette possibilité plus qu'éventuelle.
 
Par contre tu dénigres le SlimX sur la qualité audio a tort: ses limitations tiennet des retrictions du Codec utilisés et non de l'appareil: crois tu bénéficier d'une qualité supérieure sur PC meme avec une Audigy et des enceintes de Ouf?????  
 
Dans ts les cas je tacherais de tenir compte de tes preécisions dan sl aprochaine màj qui n'est hélas pas pour tt de suite.
 
 
A plus

gURuBoOleZZ a écrit a écrit : Dis donc, ton test mp3 / Slim-X s'est un peu amélioré, mais il reste quelques points contestables, voire risible :     http://julos.girard.free.fr/   Test du SlimX par Tang   (dédié à la sémillante Aurélie ;-)       J'ai donc moi-même comparé les courbes de fréquences de mon ABR avec du CBR 192kbps (avec Cool Edit version démo) et la comparaison m'a semblé tout à fait concluante... A vous de voir donc mais pour ma part je serais "bon apotre" et j'encoderai désormais en CBR en vertu du principe de précaution!   Essaie de tester avec tes oreilles plutôt ; la courbe fréquentielle ne t'apprendra rien, pas en tout cas en ce qui concerne la qualité d'un encodeur perceptuel.   ...Variable Bit Rate  (...) souvent retenu pour les codecs récents tels le prometteur Ogg Vorbis ou l'exceptionnell MpegPlus - mais pas le génial mp3pro   Le mp3pro VBR existe depuis 3 mois   Si toutefois vous vous défiez des avantages par trop théoriques du VBR je vous conseille plusieurs solutions CBR   Le VBR ne présente pas que des avantages théoriques, mais aussi et surtout (c'est sa raison d'être) perceptifs. On utilise le CBR que par contrainte technique, et non à des fins qualitatives (320 exclu).   Mr.Qualité à Codec Blade v1.01 CBR 256kbps Stéreo (ce codec ne permet pas le JS!) : un mp3 de ce type fait un certain poids mais la qualité devrait etre indiscernable de l'original y compris pour les tympans quatre étoiles...   Tares du codec Blade :   No lowpassing wrong transcient detection too late short block switching bad reservoir handling no joint stereo non optimal huffman compression a lot of bugs everywhere wrong ath bad best quantization selection no scalefactor use no scfsi   L'auteur de la litanie est Gabriel Bouvigne, qui développe avec d'autres LAME et qui fréquente assidument ce forum... Tu peux lui demander quelques précisions à ce sujet. Blade est un codec MacDo, et pas du tout « Quatre Étoiles » !   Mr.Qualité/PoidsPressé à Codec GOGO v2.39 (définitive!)   La version 3 (3.1) est sortie, et bien avant le Slim-X que tu as testé. Elle est largement meilleure par défaut - plus lente aussi certainement.   Et le plus fun :   / !\ Important : A noter que le codec Lame est ASOLUMENT à prescrire aux bitrates 224kbps et 256kbps car des bugs dégradent le son de manière inadmissible et le résultat est plus proche du Real Audio que d'autre chose ;-)!!!   D'ailleurs, le Slim-X est plus proche d'un poste radio à galène     Le manque de logique de cette assertion ne t'a pas dérangé ? Tu n'as pas cherché à la vérifier ? J'aimerais que tu m'envoie un seul échantillon LAME 224-256 qui soit « inadmissiblement » dégradé sans l'être à 192. Quand on réalise un test, on le fait jusqu'au bout, sans colporter des anneries de « manière indmissible ».     Il te reste donc encore des choses à corriger (il me semble que tu as déjà réalisé qq retouches depuis deux moins, non ?). Parce qu'avec un tel feu d'artifice, on se sent pas trop en confiance avec la partie technique du test (qui est vraiment complet d'ailleurs, et regorge d'infos : félicitation - sincèrement).

 
Deux raisons pour prendre l'info avec des pincettes, et d'aller vérifier avant que de le répetér en caranctère gras. Je le répète : tu ne tireras rien d'une courbe d'écoute générale. J'en ai refais l'expérience récemment (cf mon « CHOC DES TITANS ») : arrive en tête le mpc, suivi de l'acc puis de l'ogg. Et pourtant les fichiers qui « respectent » le mieux les hautes fréquences sont les plus mauvais à l'écoute : ça monte haut, mais ça déborde aussi sur les côtés... Et pour voir ce qu'on entend pourtant très bien, la courbe générale n'est d'aucun secours... Il faut s'approcher (loupe, zoom) de très près, ce qu'a oublié de faire ton magazine, qui aurait été mieux inspiré de juger le son de façon auditive que de façon visuelle... La logique d'ailleurs y gagne paraît-il
 
 
Idem pour Blade qui m'a tjrs paru avoir bonne réputation du reste.
 
Il aurait fallu faire des tests d'écoute approfondis avant que de se prononcer. C'est pénible, je le sais... Pas grave, mets juste tes infos à jour maintenant (note que Blade est surtout détestable à bas débit : < 192 kb/s)
 
 
A noter que pour le VBR tu me concederas que ce mode n'a été implémenté au mp3 que sur le tard ce qui peut susciter des doutes quand à son adaptation à ce codec pensé initialement pour le CBR...
 
Oui, mais tu me concèderas de même qu'avec des doutes on peut finir par supposer plein de chose : on a peur pour le joint stéréo [que tu n'utilises pas...], l'idée de compression du son aussi parait insensée, etc... D'ailleurs, la norme mp3 intègre pleinement le VBR : je ne suis pas sûr qu'on puisse parler d'adaptation sur le tard... de développement peut-être.
Encore une fois, mieux vaut réaliser des tests dans ces cas là que de refuser une technique par supsicion. Le VBR du mp3 n'est pas le meilleur, ni le plus intelligent : il fonctionne par gros pallier, ce qui occasionne une dépense inutile d'espace, contrairement à Vorbis ou Musepack. Mais il fonctionne, d'autant mieux qu'il a été l'objet d'un travail intense : avec LAME, on peine à imaginer que le mp3 souffre de lacunes natives en ce domaine.

 
 
 
Enfin quand je dis que le VBR est l'avenir de la compression audio c'est parcerque meme si en terme de quelité le mp3 est déjà dépassé il reste LE codec utilisé par la majorité (...) et si tu regardes la part du VBR MP3 sur le net lle est minime. C'est en ce sens que le VBR est l'avenir et non le p^résent.
 
Vu ainsi, tu as raison. Mais évite d'énoncer un principe (par essence « théorique ») pour exprimer un constat pratique - ou alors soit plus précis.
 
 
Par contre tu dénigres le SlimX sur la qualité audio a tort: ses limitations tiennet des retrictions du Codec utilisés et non de l'appareil: crois tu bénéficier d'une qualité supérieure sur PC meme avec une Audigy et des enceintes de Ouf?????
 
Bien entendu, j'étais tout à fait sérieux en comparant le discman à un poste de radio des années 20    
Le smiley «   », comme l'aberration de mes propos auraient du te mettre la puce à l'oreille : ironie pour fustiger ton attitude qui consiste à répéter sans test un constat tiers qui manque de logique (« les défauts inadmissibles » de LAME 256...). Dans ces cas, on se montre prudent, et faute de vérification, on met de gros bémols, et pas des avertissements en caractère gras !
Cela nuit injustement à la réputation du codec, et insulte le travail des développeurs, qui passent pour de gros benêts.

Salut gURuBoOleZZ, j'ai une petite question: habitué a easy comme tu dois le savoir, je viens de mettre la 1.5beta7 pour tester... Peux tu m'indiquer en gros a quoi correspondent les 2 modes que j'utilisais avec easy: abr 192kbps et abr 256kbps en alt preset (puisque tu me dis que c'est le mieux)? Parceque la ces standars, extreme et tout ca me dit pas grand chose...
 
Merci  

romf a écrit a écrit : Salut gURuBoOleZZ, j'ai une petite question: habitué a easy comme tu dois le savoir, je viens de mettre la 1.5beta7 pour tester... Peux tu m'indiquer en gros a quoi correspondent les 2 modes que j'utilisais avec easy: abr 192kbps et abr 256kbps en alt preset (puisque tu me dis que c'est le mieux)? Parceque la ces standars, extreme et tout ca me dit pas grand chose...   Merci

 
Les --alt-preset abr sont inclus dans Cdex (bas de la fenêtre déoulante).
Tu peux toutefois obtenir une bien meilleure qualité aux même débits :  
 
--alt-preset standard (190-210 kb/s)
--alt-preset extreme (autour de 250)
C'est plus lent, mais sensiblement meilleur.
 
Si tu cherches à reproduire les --alt-preset VBR sous Easy CDDA, sache que c'est impossible : les preset VBR ne sont pas reproductibles par switches.
Maintenant, il est possible qu'Easy5 dispose d'une .dll de Lame autorisant les --alt-preset : à toi de voir. Je ne paierais pas 25$ pour le savoir

Slt guru
on se retrouve de mdfr au mp3...
bref
le lien du guide sur le musepack il marche pas tu pourrais y jeter un coup d`oeil?
a+
neith

gURuBoOleZZ a écrit a écrit :     Les --alt-preset abr sont inclus dans Cdex (bas de la fenêtre déoulante). Tu peux toutefois obtenir une bien meilleure qualité aux même débits :     --alt-preset standard (190-210 kb/s) --alt-preset extreme (autour de 250) C'est plus lent, mais sensiblement meilleur.   Si tu cherches à reproduire les --alt-preset VBR sous Easy CDDA, sache que c'est impossible : les preset VBR ne sont pas reproductibles par switches. Maintenant, il est possible qu'Easy5 dispose d'une .dll de Lame autorisant les --alt-preset : à toi de voir. Je ne paierais pas 25$ pour le savoir

 
pas de problème, ce soft a l'air pas mal, puisqu'il permet une meilleure qualité je m'y met  
Donc merci pour ta reponse, je vais donc utiliser
--alt-preset standard
et
--alt-preset extreme...
 
Autre question est il utile de configurer le lecteur dans les options ou non?

Et une autre aussi: quand je met le extreme, j'ai bitrate min/max:128/224... donc ce sera forcément moins que 250 non?

Salut, Neith...
Les liens sont corrigés. Merci de me l'avoir signalé.
 
Je ne sais pas si tu as vu la nouvelle fonction du forum, tout en haut du premier message, avant l'encadré : on trouve des renvois aux topics similaires. Ce sont eux qu'il faut privilégier.
 
 

romf > Pour le paramétrage dans Cdex du lecteur CDrom, je pense que l'utilité est limitée. On s'y rends en cas de problème. EAC est bien meilleur de ce point de vue.
 
romf > pour --alt-preset extreme, il me fait la même chose par défaut. Je viens d'encoder une plage, et aucune plage n'est encodée à plus de 224 !!! Ce qui ruine l'intérêt des --alt-preset ?! Quand est-ce que les développeurs comprendront qu'il faut BLOQUER ces options avec ces presets particuliers !!!
Passe en 320 max et VBR=2 ; mais je suis pas certain que cela correspon au vrai --alt-preset extreme. Je vais tester cela.

 
OK merci beaucoup de ton aide c'est très sympa
 
Oublies pas de poster tes résultats. moi je vais me coucher. A demain    

J'ai testé cela sur une plage : il existe une légère différence en taille entre l'encodage Cdex VBR=2 et 128-320, et le véritable --alt-preset obtenu avec LAME 3.92 (compilation Mitiok) :  
 

 
Trois fois rien...
La différence devient dérisoire lorsqu'on songe à désactiver la présence d'ID tag dans Cdex    
 

 
 
Bref, 164 octets d'écart, qu'on peut imputer sans doute à de légères différences entre la .dll et le .exe, peut-être aussi au compilateur. On peut raisonnablement supposer qu'il suffit de repositionner les paramètres afin qu'ils coïncident avec ceux des --alt-preset :  
 
Bitrate MIN = 128 kb/s
Bitrate MAX = 320 kb/s
Private :      [ ]
Checksum : [ ]
Original :     [ ]
Copyright :  [ ]
VBR quality : VBR2
Output samplerate : 44100
 
 
Une fois de plus, les caprices de configuration ne sont pas à mettre à l'actif du seul EAC, qui lui permet un altpresetage digne de confiance...
 
 
Autre solution, pour être certain de bénéficier du vrai potentiel des --alt-preset :  
 
Choisir comme format EXTERNAL ENCODER, entrer le chemin pour LAME.EXE et taper --alt-preset standard %1 %2
La, normallement, c'est parfait.