Reprise du message précédent :
ouppsss pardon.
Oui, c'est plus clair. A -q x lossless, les artefacts seront moindres u'à -q x lossy. On est d'accord.
Moi aussi, pour l'usage que je fait de la compression, 25 % ne pose pas de problème. Pour un balladeur en revanche, j'aurais moins de scrupules.

Heuuu...   désolé de vous déranger les gars mais je cherche une chtit page internet ou serai référencé tous les presets du MusePack ou au moins une grande partie, et si c'etait expliqué ce serai encore mieux.
 
Histoire que tout le monde qui s'interesse à ce format s'y retrouve un petit peu au cas ou l'on veuille approfondir les presets "grand public".
 
Merci d'avance !!
 
Ps: quelques liens sont mort (momentanément j'espere) en 1ere page de ce topic.
 
Voili !

Les presets Musepack  sont :  
 
-thumb (qualité merdique)
-radio (qualité déjà bonne)
-standard (qualité excellente)
-extreme (qualité plus qu'excellente)
-insane (qualité supérieure à plus qu'excellente)
-braindead ([/syntax error - no word matching for describing this preset]
 
Ils correspondent, pour les 3 plus célèbres, à ceci (à vérifier toutefois avec la dernière version de l'encodeur) :
 
standard profile, "--standard" =  
--bw 22050 --ltq ank --ltq_gain 0 --ltq_max 83 --minsmr 0 --nmt 6 --tmn 18 --tmpmask 1 --ms 2 --cvd 1 --ans 5  
 
 
extreme profile, "--extreme" =  
--bw 22050 --ltq fil --ltq_gain 0 --ltq_max 83 --minsmr 0 --nmt 8 --tmn 20 --tmpmask 1 --ms 2 --cvd 1 --ans 5  
 
 
insane profile, "--insane" =  
--bw 22050 --ltq fil --ltq_gain -6 --ltq_max 77 --minsmr 3 --nmt 9 --tmn 24 --tmpmask 1 --ms 2 --cvd 1 --ans 2  
 
source : http://snow.prohosting.com/xmixahlx/musepack.html
 
Pour avoir des infos lors de l'encodage, ajoute --verbose --verbose à ta ligne.
 
--braindead --verbose --verbose.
 
 
Pour la description des switches : http://www.uni-jena.de/~pfk/mpp/manual.txt

[jfdsdjhfuetppo]--Message édité par gURuBoOleZZ--[/jfdsdjhfuetppo]

Merci c'est top d'avoir des reponses aussi claires Guru.  
 
Je pense que ces deux pages devraient figurer dans la centralisation de la premiere page du topic, si Antigone passe    !

Certains liens sont à mettre à jour. Antigone le fera à son retour  

j'ai une petite question :   pourquoi le MPC ne sera-t-il probablement pas utilisable sur des balladeurs CD ??
Il ne suffirait pas de mettre a jour le Bios ?
 
a+
nico

[jfdsdjhfuetppo]--Message édité par nicola04--[/jfdsdjhfuetppo]

Le problème n'est pas technique : Musepack ne demande quasiment aucune ressource au décodage (vitesse x200 sur 1 Ghz !). Il est juridique : Musepack exploite une technologie brevetée (norme mpeg), qui n'est pas rémunérée, et qui en plus ne respecte pas la norme. Tout constructeur qui déciderait de sortir un décompresseur hardware pourrait être poussé devant un tribunal. Evidemment, on peut toujours espérer que des développeurs indépendants se chargent de l'upgrade. Mais pour cela il faudrait que la doc des iovolt & Cie soit disponible.

Vanter le wma et le streaming dans un topic dédié à Musepack    
 
Mais inutile d'insister dessus, tu l'a dit toi même : c'est un codec de streaming, les autres : de téléchargement (ou de confection personnelle - d'ARCHIVAGE). L'objet de ce topic était de présenter les avantages d'un format qui tire son fondement de la volonté d'archiver.
Personne ne tape ici sur le wma : c'est tellement mauvais pour l'usage qu'Antigone et pas mal d'autres souhaitent. Sans parler de leur foutue protection de merde, qui alimente les forums d'un pigeon par jour (help, comment passer mes wma en mp3...).
 
 

 
Puisque tu abordes le sujet, pouurais-tu expliciter les raisons pour lesquelles la version 8 du codec possède une sonorité plus métallique (et de fait plus mauvaise) que la version 7. Il me semble que tu sais qq chose sur ce point qui m'intrigue.
 

 
Beh oui, quand on se tire une balle dans la jambe, faudra pas se plaindre d'avancer moins vite que les autres  

Attention a vos interprétations les gars...
Ivan n'a jamais dit qu'il avait qqch contre le joint stéréo. Il a juste parlé du "lossy joint stereo", en gros l'intensity stereo.
Par contre, il est clair que son codec aac utilise le joint stereo en mode m/s, qui n'est pas destructif.
 
Pour les résolutions temporelles, oui le mp2/mpc a une meilleure résolution.
Une fenetre mp3 fait 1152 échantillons (donc la durée de la fenetre dépend de la fréquence d'échantillonage) pour un bloc long, ou 3*384 pour un bloc court.

Pour le wma: attention a ne pas vous faire avoir par MS. Ils sont très fort pour ce qui est des phrases ambigues.
 
Le mythe du wma cbr: ce n'est pas forcément vrai. Meme si les frames de données ont une taille constante, rien ne dit que les informations audio ont une taille constante. C'est comme avec le mp3: si vous encodez en cbr, le bitrate du fichier/bitstream sera constant, mais les données audio n'ont pas pour autant une taille constante, du fait du bit reservoir. La seule chose sure à propos du wma, c'est que le débit du fichier/bistream est constant.
 
Le mythe du wma "full stereo": les gens de chez MS n'ont jamais dit qu'il n'employaient pas de joint stereo. Ils ont juste montré que leur codec ne détruisant pas des infos de stéréo, même à bas débit. Cela peut vouloir dire 2 chose: ils peuvent utiliser un mode intensity stereo bien fait et suffisamment intelligent pour qu'il ne soit activé que quand ce n'est pas nuisible, et ils peuvent aussi utiliser du middle/side stereo qui lui n'est pas destructif.
Ms vous a juste poussé à penser qu'ils n'utilisent pas de joint stereo du tout, mais ils ne l'ont pas clairement dit.
 
(en plus je ne vois pas en quoi cela ferait du wma un codec supérieur: si ils font de mauvais choix technologiques, ça n'en fait pas un meilleur codec)

Encore un truc: je ne vois pas pourquoi il faudrait un codec purement cbr pour faire du streaming. Le mode abr de lame, par exemple, marche très bien pour le streaming

D'ailleurs, au sujet du wma, comment expliquer que le débit demandé n'est pas vraiment respecté, surtout si le morceau est morceau de test, particulièrement complexe ? Est-ce vraiment du pur CBR ? Et sous LAME, le bit reservoir n'est-il pas désactivable ? D'ailleurs, si je ne me trompe, ce réservoir est mince (511 bits max, mais par quoi ? par frame ? )

Ben pour le débit de wma c'est facile: Ms n'a pas le mêmes unités de mesure que le reste du monde.
 
Pour eux 1 kbit fait 1024bits alors que pour le reste du monde 1kbit fait 1000bits. C'est 1kByte ( ie 1k Octet) qui fait 1024 bytes. C'est pour ça que 64kbps en wma ça fait un fichier plus gros que 64kbps en mp1/mp2/mp3/aac/ac2/ac3/.....

 
Ce serait facile...  
Les fichiers wma de durée égale auraient tous la même taille. Or celle-ci varie en fonction de la complexité du sample. Je vien d'essayer sur un fatboy modifié : c'est du 140 k/s que $oft me pond. C'est plus du 1000 ou du 1024, mais du 1100 carrément.
 

Bon et bien au moins c'est clair: c'est pas cbr du tout mais abr

 
Si je ne me trompe, les amateurs de DivX doivent pouvoir le confirmer : le wma8 ne passe pas pour cette raison. Mais là encore, je demande confirmation. Des amateurs comme de Kobaia.

C'est marrant, on dirais que tu cherches à ce qu'il y ait de l'animation sur ce forum...
 
Sinon, faudrais que tu m'explique où je me contredis.
 
Pour finir ce post, une explication cbr/abr:
Ces modes réferrent aux frames de données.  
 
En mode cbr,le débit de données est constant, toutes les frames ont la même taille (à 1 octet près à cause du padding si tu veux vraiment chipoter). Mais cela ne veux pas dire que la quantité de bits concernant chaque fenetre de 1152 échantillons soit constante. (il y a une sorte de buffer - le réservoir- qui fait partie de la norme mp3 et qui est géré à l'intérieur des frames)
 
En mode abr, le débit des données n'est pas constant, on utilise des frames de tailles différentes. Par contre l'encodeur s'assure que le débit constant soit très proche du débit demandé.
 
Si tu veux des explications, tu n'as qu'à demander. Mais pourquoi agresser les gens quand qqch t'échappe?

Désolé, mais on a que des indices et des éléments "probables" au sujet du wma, pas de certitudes.
 
Je crois que cette citation de Amir Majidimehr résume bien la situation:
"Me, neutral? Nah... you are going to get me fired this way"

 
Le problème c'est que j'ai plus de 200 CD à encoder : un millier à moi, qq centaines à d'autres. Defsiam a choisi MonkeyAudio, sans doute par ce qu'il en a moins à compresser. J'ai aussi paumé 2 DD récemment, leur contenu aussi (pour un seul seulement). Pour archiver, faut au moins 2 DD, ou alors regraver.  Et mettre 2h30 sur un CD-R : pas top ; j'en met 6 avec Musepack, pour une qualité perceptivement identique, le format permettant le transcodage.
Evidemment que le CDaudio est plus universel ; dire qu'il est moins cher   Si je compresse, c'est pour éviter d'en graver 500 tous les ans, que je n'écoute de toute manière quasiment jamais.
 

 
C'est du WMA v4 (ou 2). S'il l'utilise, c'est qu'il est meilleur que le mp3 à ce débit. Il n'a jamais dit en revanche que le format était bon. Le mp3pro est « PLUS efficace..PLUS performant :-)) », tant pis pour $ost et sa fiche technique. On peut pas l'intégrer à un DivX faut de filtre. Encore une fois, ce sont l'usage et la réalité qualitative (et non le potentiel) qui sont privilégiés...

antigone a écrit a écrit : Si ton but est l'archivage avec possibilité de changer de format dans le futur, pas de problème, je comprends très bien   Chacun ses choix ; j'ai déjà une excellente confiance dans --extreme -nmt 10       Une dernière chose, j'ai vu que le MPC est en fait encore plus adaptatif que je ne le croyais, puisque le bitrate peut monter à 1200 kbit/s en pointe (contre 320 pour le MP3 et 400 pour l'OGG) !!!       Bref, c'est vraiment de la balle ce format

 
 
Sans vouloir être désagréable, si t'en arrives à des bitrates de 1200, autant garder le wav d'origine.....

 
   
Belle conclusion. On parlait de cas extrême ; autrement dit les rares secondes purement artificielles qui demandent un débit phénomal en raison de l'incompressibilité du signal.
Musepack autorise un tel débit, qui en pratique n'est jamais sollicité. C'est un des désavantages du mp3 que d'être bridé à 320 lors d'un encodage en vbr : le format serait plus sécurisé d'un point de vue qualitatif si le codec pouvait, en certains passages, monter à 500 k/s et plus. Au final, la taille du fichier serait presque la même, et les défauts les plus grossiers disparaîtraient.

[jfdsdjhfuetppo]--Message édité par gURuBoOleZZ--[/jfdsdjhfuetppo]

@Macolu : fo lire tout : c'est écrit en pointe !!!

[jfdsdjhfuetppo]--Message édité par jotenakis--[/jfdsdjhfuetppo]

200 eme !!!!!
 
 
 

Pas encore couche toi ???

Pfff... le soleil n'est même pas levé  

 
Ben si quand même... Imagine que tu ais un fichier ABR en 160 kbps...
Il y a du silence ou signal très simple : 32kbps pendant 1000 frames puis du son complexe : 320kbps pendant 100 frames. Le problème qu'il y a c'est que sur le net (le streaming sur une ligne à débit fixe il y a pas les mêmes pbs, juste le retard à gérer) c'est que si ta ligne fait 160kbps max. Pendant les trames de 32 kbps, la bande passante sera utilisée pour autre chose. Et pour le 320 kbps ben ca aura du mal à passer sur du 160 kbps, même avec beaucoup de buffering à la réception (pour se prémunir contre ce genre de cas). Bref l'ABR (ou VBR) est mal adapté à ce genre de situation. Il oblige en particulier à mettre trop de bufferisation  à la réception, d'où un certain retard (en plus du temps de transmission).

En analysant mes abr (170-180 k/s) avec encspot, j'ai pu remarquer que les frames à 320 sont quasi inexistantes. En fait, sont principalement concernés les valeurs adjacentes du bitrate souhaité :
 
Exemple, avec deux fichiers dont le bitrate moyen est le même, l'un en ABR, l'autre en VBR :  
 
 

• LAME 3.91 ABR 167 k/s

 
Quatuor 2, Op 18-2 - IV Allegro molto, quasi Presto.mp3
--------------------------------------------------
Bitrates:
 
 32     |||                                             4.6%
 80                                                     0.0%
160     ||||||||||||||||||||||||||||||||||||||||       53.4%
192     ||||||||||||||||||||||||||||||                 41.2%
224                                                     0.7%
256                                                     0.1%
----------------------------------------------------
 
Type                : mpeg 1 layer III
Bitrate             : 167
Mode                : joint stereo
Frequency           : 44100 Hz
Frames              : 12529
Length              : 00:05:27
Encoder             : Lame 3.90
 
--[ EncSpot 1.0 ]--[ http://www.guerillasoft.com ]--
 
 

• LAME 3.91 VBR 167 k/s

Bax. Sonate pour flute et harpe - I. Allegro moderato.mp3
--------------------------------------------------
Bitrates:
--
 32                                                     0.0%
128     |||||||||||||||||||||||||||||||                27.5%
160     ||||||||||||||||||||||||||||||||||||||||       34.6%
192     ||||||||||||||||||||||||||||||||||             30.2%
224     |||||||                                         6.2%
256     |                                               0.9%
320                                                     0.5%
----------------------------------------------------
 
Type                : mpeg 1 layer III
Bitrate             : 166
Mode                : joint stereo
Frequency           : 44100 Hz
Frames              : 15814
Length              : 00:06:53
Encoder             : Lame 3.91
 
--[ EncSpot 1.0 ]--[ http://www.guerillasoft.com ]--
 
 
 
L'ABR semble être bien plus propice au streaming que le VBR, puisque les frames > à 192 k/s sont quasi inexistantes. Les variations se limitent à deux palliers, trois au maximum (dont un seul est supérieur à la valeur souhaitée). Bien entendu, il est possible de fixer une valeur plafond, afin de ne pas dépasser les 192 en aucun cas.

[jfdsdjhfuetppo]--Message édité par gURuBoOleZZ--[/jfdsdjhfuetppo]

L'abr ne fera pas du 320kbps pendant 100frames. Il essaye en permanence de respecter le bitrate cible.
Ce n'est pas comme du vbr en 2 passes qui essayerait de respecter seulement en global et se permettrait des long passages avec déviation du bitrate.

Oulala je vois que le topic a beaucoup évolué durant mon absence (pour cause de déplacement professionel).
 
Je reviens ce week-end (dimanche) pour mettre à jour la 1ère page (liens et ajouts) et répondre à certains
 
A+
Antigone

Illustration:
 
http://gabriel.mp3-tech.org/abr.png
http://gabriel.mp3-tech.org/vbr.png
 
C'est la même piste, avec le meme bitrate final

 
Pardonne moi au passage de ne pas y connaître gd chose au streaming. J'ai posté ces stats en réponse à Robux4 : 32kbps pendant 1000 frames puis du son complexe : 320kbps pendant 100 frames.. Mes stats doivent suffire je pense à dire que le cas de figure proposé ne se posait pas du tout avec l'ABR, et même très peu avec le VBR (moins fiable cependant sur le sujet).

J'aurai du préciser que les valeurs que je citent sont à titre d'exemple. Pour grossir le problème pour qu'il soit plus visible. Je sais bien qu'il ne se produira jamais (en tout cas avec LAME en ABR).

encspot pro  

Tiens, Antigone, comme je vois que tu ne reviens plus sur l?autre topic ?
 
Suite à notre discussion "EAC vs. Paranoïa", tu pérorais sur les 99,9% d'égalité au point de vue performance des 2 softs et me réclamait des excuses sur le fait que je me trompais lourdement ... Comme je vois que tu n'essayes plus de contrecarrer mes arguments ... devrais-je en conclure que c'est plutôt toi qui doit faire face à la défaite ?
 
En rapport avec ce topic-ci : http://forum.hardware.fr/forum2.ph [...] ic=&trash=
 
Et en reprenant tes propres mots : "Dans ta réponse, tu aurais pu au moins t'excuser de t'être trompé..."
 
     

Tiens au fait, pour gerer les tags de la SV8 faudra attendre que M.A.C soit updaté ou alors il sait deja le gérer?
 
Ou prendre un autre soft de tagging, mais lequel?

 
 
Il faudra impérativement un soft qui puisse gérer les ape tags v.2. Actuellement, c'est assez difficile à programmer, puisqu'il semble que les spécifications de la version 2 des tags « ape » ne soient pas finalisées. Pas de tags, pas de softs donc.
 
Actuellement, MAC ne permet que de tagger les musepacks en ID v1 (voire, au mieux, en IDv1.1).
Pour tagger en ape v1, mieux vaut le soft savamment nommé « TAG », disponible >> ICI << (lien direct = ICI)
 
Je rappelle que l'avantage d'un tag ape est de ne pas être borné aux 30 premiers caractères. C'est un pis allé, mais ça peut suffire.
 
 
 
A noter aussi que Musepack sera à même d'encoder à partir d'un fichier MonkeyAudio (après optimFROG, Rkau, szip...) : dès maintenant pour les utilisateurs de Linux, et lundi pour les utilisateurs de Windows... utile pour ceux qui comptent migrer du lossless au lossy, ou pour ceux qui gravent massivement leur CD avec des fichiers Monkey pour faire qq économies. Defsiam, tu pourras te lancer dans Musepack    
 
 
 

 
Source : http://www.uni-jena.de/~pfk/mpp/

[jfdsdjhfuetppo]--Message édité par gURuBoOleZZ--[/jfdsdjhfuetppo]

Ben oui, je comprends ce qu'est la prédiction, mais dans le mp3 je la cherche toujours...
 
En mp3 on prédit rien, on a toujours toutes les données. C'est en aac qu'il y a un peu de prédiction.

 
 
http://www.psytel-research.co.yu/mpeg.htm :  
 
Frame Prediction AAC Yes (Long Term Predictor)  MPEG No

INFOS DE MISES A JOUR  
================
 
 
 
Deuxième version post-mortem de Musepack SV7, avec corrections d'un bug concernant cette fois l'apparition, en de rares cas, de « gap » entre deux morceaux
 
 

• First files with exact 1152*n samples per channels are 1152 samples too short after decoding. This can be fixed either by using the new encoder or the new decoder (or both). 1.04% of CD files are affected.  

• The much larger problem is that files with 1152*n + 880...1151 samples have a level loss in the last 0...270 samples. This can only be fixed by re-encoding. If needed mppdec can be added by a check feature for this problem for testing existing files.

• There are major changes in an error prone style to fix this problem in SV7. You need new encoder and new decoder(s) to fix the problem. [#f00e00]Be careful, it is not fully tested. Try to find out that the problem is really fixed and that there are no additional problems introduced.

Source : http://www.hydrogenaudio.org/forum [...] #post13734
 
Pour plus d'infos sur la discussion qui a motivé ce changement :  
Hydrogenaudio : Is gapless MPC encoding possible ?. Bel exemple de la vivacité et du fonctionnement d'une communauté, prouvant aussi que l'open source n'est pas pleinement indispensable.
 
 
 
 
Liens :
 
¤ ¤ ¤ Site officiel ¤ ¤ ¤  
 
> > ENCODEUR 1.01g < <
> > DECODEUR 1.01g < <
> > Plug-in Winamp 0.92g < <
 
 
Pour plus d'infos sur les changements apportés : CE TOPIC

Thanx Guru.
 
 
Est-il normal que Encspot 2.0 ne sache pas donner d'information sur des mpc encodés en "--insane" (mppenc-windows-1.01g)?
 
alors qu'il en donne sur les mpc "--insane --ms 0"  ?

 
 
Depuis la 1.01, encoder avec le switch --ms 0 donne DES L'ENCODAGE UN PROFIL NOMME « telephone » : (pour en savoir plus : >> ICI << )
 
En fait, Frank Klemm a introduit une protection sommaire contre les bidouillages intempestifs des presets de Musepack : les profils peuvent être renommés automatiquement par l'encodeur si certaines options cruciales sont modifiées. Mais normalement, Encspot doit pouvoir afficher les profils attribué par le codec. Je vérifierais plus tard.

[jfdsdjhfuetppo]--Message édité par gURuBoOleZZ--[/jfdsdjhfuetppo]