Reprise du message précédent :
Vous remarquerez messieurs que j'ai dit que je n'utilisais cet encodage en cascade que pour connaitre le type d'artefact créé par le mpc, rien de plus.
Il est facilement démontrable qu'un codec peut être meilleur en cascade qu'un autre en étant bien moins bon sur le premier encodage
Il suffit pour s'en convaincre de prendre un codec qui ne fait que supprimer les fréquences supérieure à 10KHz et un codec mp3 ou mpc. Le premier codec sera mauvais sur le premier encodage mais les suivants seront identiques au premier. Pas les autres ou la qualité se dégradera à chaque réencodage.
 
Le reste de mes tests est constitué d'écoutes de morceaux encodées en 1 seule fois (seul test valable à mes yeux), mais en essayant de repérer les artefacts déjà cités, ou d'autre (car la cascade ne permet pas de mettre en avant tous les défauts, comme déjà démontré ci dessus).
 
J'ajouterais ceci concernant les signaux musicaux :
la techno utilise des sonorités parfois étonnante, le temps de monté sur certains morceaux est extrèmement faible (terrible pour le mp3, mais le mpc est je trouve bon sur cet exercice)
 
un bon codec doit savoir encoder la petite musique de nuit de Mozart, mais aussi sur une pluie de percussion. C'est ça la grande difficulté.
 
Semble t'il le mpc n'aime pas les morceaux saturés (il faut que je test revolution des Beatles) ce qui m'empèche d'utiliser le preset standard seul, dommage. Je ferais un tour sur hydrogenaudio (merci Guru pour le lien   ) pour voir si il y a d'autres informations sur le sujet
 
Pour terminer, je rapelles que je fais ces tests uniquement pour moi, pour savoir si le mpc a un avenir dans ma discothèque, non un avenir dans le monde de la musique car ça ce n'est pas moi qui en décide.
 
 
PS : j'utilise le musepack 1.04

 
Euh... 3dB ca serait pas plutôt --scale 0.500 ??? (ou alors 1/racine(2) )

 
   
 
Moi et les maths  

ça dépend si scale est lineaire ou logarithmique, je regarde...

extrait de la doc de lame :
--scale <arg>   multiply PCM input by <arg>
 
donc il semble que ce soit lineaire, donc --scale 0.5 = -3dB
 
donc  
--scale 0.976 equivaut à 10log 0.976 = -0.1 dB, donc autant dire rien du tout
 
par contre la transformation signal de départ => signal * 0.976 est quand même à éviter car elle ajoute du bruit de quantification, c'est de l'approximation de bits de poids faible

Mais heureusement le scale est appliqué sur des flotants at pas sur les entiers 16bits (sinon ce serait pas terrible)

bien joué

Tiens, si tu trouves le temps, je te suggère d'essayer d'autres versions du codec. La 1.04 est assez décriée, en raison d'une baisse parfois énorme du bitrate sur certains morceaux, sans toutefois qu'une dégradation, même infime, de la qualité sur ces plages ait été détectée.
 
Une version 1.05z (1.06 RC1) est dispo depuis trois heures (>> le lien <<)
 
L'ancienne version originale du codec, développée par Buschmann, garde parait-il des adeptes (Page officielle). ATTENTION : elle ne fonctionne pas avec les gui actuelles !!! Si tu veux en tirer partie, utilises EAC ou l'interface de Monkey Audio [car en fait, ce qui fait échec à l'encodage, c'est le « -- » des versions actuelles, qui ont remplacé le simple « - ».

j'encode mes tests par batch
je regarde cette nouvelle version. la 1.05z fait elle des économies comme la 1.04 ?

Elle participe au mouvement de  restructuration « profonde » du codec initié par Klemm en vue d'une SV8 qui sortira bientôt. Quant à savoir si le débit moyen descend, du moins sur certaines plages, il faut tester. D'après les premières indications qui figurent sur le topic d'HA cité plus haut, le débit moyen retrouve pas mal de son niveau d'origine. Reste à trouver des plages qui voient le débit chuter drastiquement (perso, jamais rencontrée avec la 1.04 - excepté enregistrement monophoniques).
 
D'ailleurs, tu remarqueras que l'indication de profil via le plug-in winamp révèle un charmant experimental en guise de standard/extreme... Ca reste une version de test - j'en parle ici pour la première fois, du fait qu'elle semble augurer une réelle amélioration par rapport aux anciennes versions.
 
NOTE : tu peux paramétrer cette version alla ogg vorbis :  
--quality x, où x comprends une plage de valeur comprise entre 0 et 10, décimales comprises.
--quality 5 = --standard ; 6 = extreme...

Guru comme dit précédemment, seuls les débits inférieures à 192kb/s de moyenne m'interesse pour le "successeur" du mp3
 
j'en profite pour vous donner une bonne nouvelle :
http://odin.mutschler.de/mp3ext/
nouvelle version de l'extension mp3 dans l'explorateur

J'ai une petite question gentille:
Si j'encode en Mpc Xtrem, jusqu'a quelle qualité maximale je peux transcoder en mp3 et Ogg?
Pareil avec le preset "Braindead"?

Slt à tous, vu que cela fait longtemps qu'il n'y a pas eu de mise à jour, j'ai pensé en faire une:
 
Nouvelle version 1.06 (conseillé par Frank Klemm):
 
Encodeur:
 
http://www.saunalahti.fi/~cse/mpc/ [...] s-1.06.zip
 
Décodeur:
 
http://www.saunalahti.fi/~cse/mppdec_1.06.zip
 
Voici toutes les nouveautés:
 
New options:
 
  --quality 0.0...10.0
  --tag  item=key
  --tagfile item=keyfile
  --tagfile item
  --title key
  --artist key
  --comment key
  --year key
  --releasedate key
  ...
 
 
Options with different meaning:
 
  --insane      No more full bandwidth encoding
 
  --insane, --xtreme, --braindead
                Use a lowered standard ATH, not Filburt's ATH      
       
  --minSMR      minimum encoded SMR in the encoded bandwidth
  --ltq 10...20
  --ltq 30...40
 
 
New Features:
 
  * Copy ID3V1, ID3V1.1, APE 1.0 and APE 2.0 tags from the WAV file
    directly to the Musepack file
  * Klemm tonality estimator extended from 0...10 kHz to 0...17 kHz.
    Old Tonality estimator remains above 17 kHz.
  * Encoder version number is stored in the MPC file's header
 
 
Bugfixes:
 
  * MS and LR encoded subbands have the same ATH
    (old: MS encoded had a higher ATH)
  * ATH better between 400 Hz and 1 kHz
  * more flat NMR/TMN over level function
  * Some simple code to more conservate energy in subbands
  * Limiting resolution enhancement
    for near mid- or near out-of-phase signals
  * Frequency and channel dependent variable ATH handling
 
 
Mais ce n'est pas tout, le plugin winamp en fr 0.96:
 
http://www.saunalahti.fi/~cse/mpc/ [...] ase-fr.zip
 
Je finirais cette mise à jour, par ce petit mot de Frank Klemm sur le fait d'encoder avec les hauts débits (braindead -quality 8.0 -> 8.99 et tous les autres jusqu'à quality 10.0):
 
--quality 10 is overkill. All above --quality 7 I would only use
for recording I never can get again, but not for CDs I can buy in nearly every shop.
 
code:
 
 
 
 
CDs:                --quality 5...5.5
CDs+reencoding:     --quality 5...6
unique recordings:  --quality 6...7  or lossless
 
Pour ceux qui ne parle pas Anglais, il dit que tout encodage au dessus de quality 7 ne sert pas à grand chose, sauf si c'est vraiment un CD qui ne se trouvera plus jamais sur le marché du disque...
 
Bon encodage et à bientôt...

Au fait, jugatsu, Guru nous a dit qu'il fallait rester a la 1.04 car la 1.05 était experimentale et devait etre utilisé que pour le test. Qu'en est il de celle là?
 
Peux tu nous donner le lien d'ou est tiré ton post?

Bonjour à tous,
 
La nouvelle version 1.06 est sortie récemment, encore et toujours au stade "beta"... Le lien suivant conduit à un forum où "Kevin T." prétend pouvoir prouver un manque de qualité dans cette nouvelle version : http://www.chaostar.org/phorum/rea [...] 892&t=3892
Des fichiers sont disponibles à cette adresse : http://rvcc2.raritanval.edu/ktek9053/mpctest/.
 
Personnellement, je n'entends pas vraiment de perte de qualité entre les fichiers... Alors, je fais appel à vous ! Trouvez-vous que la 1.06 a perdu de sa qualité et qu'il vaut mieux utiliser d'anciennes (1.01 ou 1.02, comme beaucoup font à présent) ?
Pour ce qui est de moi, je n'ai de toute façon pas de "Golden ears" et j'utilise le preset --xtreme, ce qui me laisse bluffé en écoutant les fichiers encodés : ils sont pour moi transparents. Mais bon, je n'aime pas avoir le moindre doute, alors j'aimerais savoir s'il est vraiment bon d'utiliser la 1.06 (au pire, il est vrai que les défauts doivent être quasiment imperceptibles et qu'on peut les 'laisser passer' puisque si l'on voulait de la qualité parfaite, mieux vaudrait utiliser du lossless que du lossy)
 
Merci à tous, audiophiles que vous êtes !

Moi je capte plus rien  
Je prends laquelle ? 1.02, 1.04 ou 1.06?

Frank Klemm conseille l'utilisation de la version 1.06, de toute façon toutes les versions au-dessus de la 1.0 sont des versions beta...
 
Perso je l'ai testé et pas de pb, certaines personnes sur Hydrogen se plaigne du fait que les nouvelles versions ont une moins bonne qualité, tout ça parce qu'il y a une baisse du bitrate, sans pour autant qu'il y ait une baisse de la qualité réelle...
 
Donc tu peux utiliser la version 1.06, sans pb surtout qu'avec la ligne --quality on se rapproche de la facilité de configuration du OGG VORBIS...

Moi je comprends toujours pas pkoa tag frontend ne fontionne pas.
 
Il me lance une fenêtre MSDOS avec "Appuyer sur une touche pour continuer". Et ça n'a rien fait

Assure toi que tu as tout les fichiers necessaires (tag + tag frontend) et que tu as dezzipeés l'integralité des fichiers du zip dans un meme dossier. Apres tape toi le fichier texte d'informations en entier.  
C'est pas une soluce miracle mais cette frontend est bizzare (mais merveilleuse)
Peut etre que tu ferais mieux d'utiliser MPC batch encoder pour Tagger tes mpcs..

OK je vais tout reprendre du début

gURuBoOleZZ a écrit

 
J'ai récemment rencontré moi-même ces problèmes de clipping, mais je ne ressens pas le problème de craquement. Savez-vous s'il s'agit d'un problème vraiment audible ou qui passe plutôt bien dans le fichier ?
 
Il m'est arrivé d'encoder des CDs en utilisant le MPC Batch Encoder sans regarder le déroulement de l'opération, si bien que je ne sais pas si des erreurs de clipping sont survenues. C'est bien pour cela que je m'inquiète !!! Dois-je tout réencoder pour m'assurer de la qualité ou bien dois-je laisser passer le problème ?
 
J'imagine qu'il y a plus de peur que de mal, mais le fait de tomber sur un problème avec ce format que je chérissais tant me fait tomber de haut.
 
Enfin, merci de votre aide.

Hier, je suis tombé sur ce probleme sur 2 titres d'un meme album, l'encodeur indique alors la manip à suivre. Il faut cependant savoir que j'ai encodé au moins 80 albums sans avoir ce problème (à ma connaissance). Si tu veux tout réencoder en restant devant l'écran, c'est ton problème, mais..............
Sous win98, la fenetre DOS ne se ferme pas automatiquement, ce qui fait que tu peux jeter un oeil à la fin, c'est déjé plus pratique.
D'ailleurs si quelqu'un sait comment faire pour que ça soit pareil avec Win2000, je suis preneur.

Euh cliquez tout simplement sur "Pause" à droite et c'est réglé, la fenêtre DOS ne se fermera pas à la fin de l'encodage! Comme ca, il suffit de noter les pistes qui ont ce clipping, avec la valeur recommendée de l'encodeur pour --scale. Ensuite vous encodez séparément les pistes qui ont du clipping, avec la bonne valeur de scale et c'est tout bon!
C'est ce que je fais en tout cas!  
 
Sinon méfiez vous quand même si vous taggez en même temps vos fichiers MPC, parce que dans les dernières versions TAG écrit pas mal de trucs, et comme la fenêtre dos a une taille maximale, il efface ensuite ce qu'il y a comme infos en haut. Donc sur un album de 13 piste, vous ne pourrez voir à la fin que les 9 dernières! Mais il doit y avoir un moyen de mettre --silent ou un truc comme ça à TAG, pour qu'il fasse son boulot sans rien dire!
 
@++

il faut absolument qu'un système automatique fasse le --scale quitte à faire un encodage, détecter le problème , réencoder tout de suite derrière avec le --scale.
ça prendra + de temps mais au moins pas de besoin de vérifier si le travail a bien été fait

Il faudrait en parler sur Hydrogen.
Il y a pas mal de fois ou j'ai encodé sans regarder la fenetre DOS : est ce que ce clipping est fréquent?  
Sachant que j'encode du classique et qu'il me semble que le clipping est lié à une histoire de saturation, je crois que j'ai peu de risque.
Quelqu'un peut il m'éclairer?

Oups, je ne regarde jamais la fenêtre dos et là vous dites qu'il peut y avoir un problème...
Bon, je pense que si il y a du clipping, cela doit s'entendre non? D'ailleurs, qu'est-ce que vous appelez du clipping?
 
J'ai écouté de nombreuses fois mes encodages, et pour l'instant, je n'ai jamais entendu de différence par rapport à l'original.
Ce problème serait-il fréquent (cela m'étonnerait, sinon peu de gens utiliserait le MPC)?

Si il y a du clipping pendant l'encodage, c'est que la source n'a pas été "mastered" correctement. C'est assez rare, à mon avis extremement rare pour du classique. Pour ce que j'encode : metal / punk / rock / ska, ça arrive un peu plus fréquemment, mais en général c'est sur un album bien précis que tu trouves pas mal de clipping, et sur les x autres rien.

Ok, merci de tes précisions.

Les mecs, je sens un mouvement de psychose inutile.
  J'ai une solution : au lieu de mettre "--standard" (par exemple), mettez "--standard --stderr C:\mppenc.log" comme ligne.
ça sert à creer un fichier log. (un rapport d'encodage au format texte, comme ceux de EAC) et vous saurez alors s'il y a eu des clippings et, s'il en a eu, la procédure à suivre.
Le fichier s'appellera "mppenc.log" et sera dans "C:" (à vous de voir si vous voulez autre chose).
Seul "hic", la fenetre DOS reste vide durant l'encodage et on ne peut plus savoir ou on en est.
Voila le topic HA ou j'ai appris tout ça et ou vous pourrez choper les renseignements à venir http://www.hydrogenaudio.org/forum [...] #post23797
 
 
Alors encodez tranquille, il n'y aura plus de clipping-intrus non- corrigés (pour peu qu'il y en ait eu)

c'est pas automatique  
moi je n'ai pas le temps de lire des .log

HAL a écrit a écrit : c'est pas automatique   moi je n'ai pas le temps de lire des .log

 
Qu'est ce qui est pas automatique?
Si parles de la correction des internal clipping, c'est vrai qu'il faut le faire manuellement et donc se taper les logs.
Moi je pense que cette technique est inutile car le clipping est très rare.

Moi je pense que le premier fichier que j'ai essayé d'encoder avait le problème (Madonna, Frozen)
 
mais bon ce n'est pas parce que moi ça me gène que ça doit géner tout le monde. ça reste un excellent encoder

Vous avez qu'a écouter du classique ou du jazz

Ouais, enfin, au final, il faut être attentif !
Savez-vous si la SV8 corrigera ce problème (ou en tout cas, fera cette manipulation automatiquement) ?

Ce problème est propre à la SV7 et je pense que les devellopeurs souhaitent le corriger.
En tous cas, ça fait couler pas mal d'encre sur Hydrogen Audio.

jaylcee a écrit a écrit : Vous avez qu'a écouter du classique ou du jazz

j'en écoute aussi

Hello,
 
Bon, étant donné que ce topic fait partie des nombreux topics qu'on n'a pas envie de relire en intégralité pour trouver une réponse à sa question, désolé si celles-ci ont déjà été posées .
 

• A quoi sert réellement le paramètre "Clipping prevention" au sein de l'interface décodage de Musedrop ?

• Quand je veux décoder certains albums avec la version 1.06, il m'affiche : "Stream was corrupted by an ID3 version 2 tagger, ignore 1080 words and 8 bits" Quelqu'un sait comment éviter cela ?

Sinon, pour ceux qui se demandetn où est passé Guruboolezz ; il est simplement en déménagement et attend une réactivation de sa connection .
Et puis, c'est justement pour décoder du Jazz ... snif snif ...

Defsiam -> Pour ta première question, je n'ai pas de réponse, par contre pour la seconde c'est trés simple:
 
Sûrement que tu as utilisé les ID3 V2, qui ne sont pas compatible avec le MPC, c'est pour cela qu'il te dit que ton fichier est corrompu. La solution est d'utiliser les ID3v1 ou encore mieux les APE Tag...

Bonjour à tous...
 
Le forum est bien vide depuis quelques temps... Vivement le retour de Guru !
Sinon, eh bien, la version 1.0 du codec OGG Vorbis est - officiellement - sortie hier. L'avez-vous testée ? Il est vrai qu'elle offre une incroyable qualité, même si certains artefacts sont parfois audibles... Je me demande si, maintenant qu'elle plus officialisée et finalisée, je ne vais pas la préférer au Musepack. En effet, le Musepack n'est pas promis à un avenir des plus certains. Alors que le Ogg, complètement libre de droit, est un petit nouveau qui fait déjà ses preuves, et qui est déjà très bien accueilli ! Surtout qu'aux birates auxquels j'utilise les deux codecs (--xtreme pour Musepack -q6.25 pour l'OGG), même si certains pourront protester et affirmer le contraire, moi, je trouve que les deux se valent, la qualité est transparente... Qu'en pensez-vous ? Croyez-vous que la version du codec Vorbis concurrence le Musepack ?
 
Bouh, ouh, ouh... c'est tellement difficile de se décider pour savoir quel format choisir, surtout qu'il faut tout réencoder à chaque fois... je suis parfois tenté de me lancer dans le lossless... plus de problèmes de qualité... mais de place... oh, c'est prise de tête à la fin... AIDEZ-MOI !!!

Je suis dans ton cas : jusqu'ici j'encodais en Musepack (en ce moment la version 1.06). Mais ces derniers temps on dirait que la qualité sonore des dernières betas n'est plus ce qu'elle était : sur le forum Hydrogen Audio, la plupart des traqueurs d'artefactes ne trouve ni standard NI XTREME transparent sur certains samples, et même pas forcément les plus durs on dirait. De l'autre coté on a un codec open source, ne dépendant d'aucune licence (genre MPEG ou autre), et qui sera certainement supporté dans le futur par plein de périph hardware (j'ai un RioVolt SP-100 donc ca m'intéresse). Et pis en -q 6, c'est transparent pour moi sur les samples que j'ai pu testé (un blind test rapide sur qqs extraits), donc j'ai commencé à encoder qqs albums en OGG et je déciderai un peu plus tard...

Moi j'avais pris en défaut la RC3 sur 2 morceaux en qualité 7, mais je n'ai pas fait de tests avec la nouvelle version 1.0.
Pour ma part, je pense que je vais rester sur le mpc, car lui je ne l'ai jamais pris en défaut.
Et puis si la qualité des dernières betas diminue comme certains le laissent entendre, alors rien ne nous empêche d'utiliser les betas précédentes.