Reprise du message précédent :

Avec quel soft?

 
Avec Foobar hélas.

Il doit y avoir un vrai problème avec la MA 3.99 et les tags puisque le bug que j'ai cité plus haut est lié aussi à des fichiers taggés. Ce n'est pas forcément lié mais c'est quand même inquiétant et c'est peut-être pas près d'être corrigé.  

Argl, vous allez finir par me faire peur
 
A la limite je repasse en 3.97

Question bête : qu'est ce qui fait qu'un format de compression looseless est meilleur qu'un autre ? puisque la qualité audio est de toute manière la même...

La vitesse de compression, le taux de compression, l'utilisation CPU à la lecture, l'absence de bugs, support en lecture...
Ce sont plus des critères pour guider son choix que des critères pour dire lequel est meilleur puisque comme tu l'as dit la qualité audio est toujours la même.
 
Mais au final, c'est bien Monkey's Audio Codec qui est le meilleur.  

rapidité d'encodage, de décodage, gestion des tags, multi-plateforme...
 
Edit: grilled mais pas tout à fait.

Et puis le fait que ce soit open-source ou proprio

C'est peut-être plus sûr.
 
Edit : Encore un problème de fichiers corrompus, sans doute à cause des tags : Forum Monkey

A ce point?  
Heureusement que je n'ai pas trop encodé cet été, mais la je vais m'y remettre...
 
A tout hasard on la trouve encore quelque part la 3.97?

Beaucoup sont en fait open-source. Bon, il n'y a pas toujours marqué GNU ou LGPL partout et c'est tout de suite moins bandant.

Beaucoup, à 2 exceptions notables au moins : Apple Lossless et wma lossless.
 
Or s'il y en a 2 qui sont susceptibles d'être intégrés dans du hardware (ce que je trouve utile pour des chaines hi-fi et complètement inutile pour des balladeurs), c'est bien ces 2 la (l'ipod lit deja l'apple lossless). Or j'ai remarqué que c'est une revendication qui apparait de plus en plus souvent.
 
Si flac ne réussit pas sa percée dans le hard, apple et crosoft risquent de s'engouffrer dedans

C'est pour ça que j'ai écrit "beaucoup" et non "tous".
Merci de l'analyse sémantique, ça peut éventuellement servir.

Bha dans une chaine HiFi, je pense que celui qui encode en lossless et a une bonne chaine Hifi, a plutot interet a se payer un petit PC avec une carte externe plutot qu'une source CD haut de gamme qui lit le lossless. Et la pas de soucis de format
 
Le seul interet du support hard est justement pour la musique nomade, car la pas de PC... Alors c'est sur que le lossless sur un petit balladeur c'est un peu debile, mais bon ca evite le transcodage quoi. C'est par exemple mon plus gros point noir : pour passer du lossloess ou mpc sur le "PC-Chaine" au balladeur, je me tape un trancodage en mp3 qui est tres long, malgre les progres immense de lame   Au point que je garde mes trancodages sur le PC, et deonc je stock en double, pour eviter de les refaire a chaques fois. Le top serait bien sur le support du mpc qui est tres rapide a encoder : le passage du wavepack au mpc est suffisament rapide pour etre fais a chaque fois sur un support type cle USB de 256Mo.

Pourquoi complètement inutile pour des baladeurs ? Les 40 Go se généralisent, ça permet de mettre environ 100 albums en lossless. Ce serait bien pratique pour ceux qui utilisent le lossless chez eux. Plus besoin de transcoder, et puis on peut avoir besoin ou envie de se servir de son baladeur comme source pour sa chaîne hifi, au moins ponctuellement.
 
Quand au Flac intégré au hardware, j'y crois autant que le MPC. Le problème de Flac, c'est qu'il a beau être open source, personne ne s'en occupe en dehors de son auteur qui n'est franchement pas réactif. Sans compter qu'il est un peu caractériel et borné. Tu me diras, c'est le problème de l'open source : le principe est le travail collaboratif et la perennité des développements. Mais la réalité, c'est que 99,99% des projets qui n'ont pas des tas de dollars derrière eux (Gnome, Mozilla etc.) sont l'oeuvre d'une seule personne et stagnent ou disparaissent quand leur auteur s'en désintéresse.

Je trouve que c'est de l'espace gaspillé pour un usage uniquement nomade, à moins d'écouter avec un vrai casque hi-fi (fermé) et un bon ampli portable pour casque. C'est sans doute plus rassurant d'avoir du lossless dans son portable mais je ne sais pas si en fin de compte on entendra vraiment la différence (dans un usage nomade avec un environnement loin d'être silencieux).
 
Par contre je comprends le problème (de temps) que peut poser le transcodage. Même si on peut laisser travailler son ordinateur seul à cette tâche la nuit.
 

Exactement ce que j'en pense. Mais ça semble parfois être un tabou que de le dire alors que c'est une évidence.

la norme MPEG4 intègre une partie codec audio. cette partie audio intègre l'AAC qui est lossy mais aussi un format lossless.
A mon avis le MPEG4 audio lossless a de bonnes chances d'être inplémenté dans du hardware

Pour moi le lossless sur un balladeur est une mauvaise idée car la durée de la batterie s'en trouverait réduite car la principale consommation de batterie est les accès disques.
(L'avantage de la qualité étant nul ou presque y compris en le branchant sur une chaine hi-fi)
 
Après c'est sur, pas besoin de transcoder... Mais bon, a mon avis ceux qui ont des 40 Go ne passent pas leur temps à mettre et enlever leur zik sur leur balladeur; une fois qu'un album y est il y est. Donc le transcodage n'a lieu qu'une seule et unique fois...
 
Sur les clefs usb c'est différent mais du lossless dessus... Hum quoi

test de transcodage de 114 fichiers APE en WV (styles de musiquer différents classique, pop/rock, techno, concerts, etc.)
en wavepack 4.10 paramètres -h -m  : 1 794 784 721 octets
en APE 3.99 preset insane : 1 725 266 479 octets
 
l'APE insane prend donc 69 518 242 octets de moins soit un gain de 3.87 % d'espace disque par rapport à la version Wavpack
 
edit : le Wavpack semble bien s'en sortir avec la musique classique puisque sur ce terrain il fait mieux chez moi que l'APE

Je suis entièrement d'accord sur l'inutilité du point de vue qualité de son.
 
Mais au contraire, c'est utiliser un codec lossy qui est du gaspillage d'espace disque, pour qui utilise au quotidien du lossless. Je prends mon exemple avec le TViX, qui a un dur de 80 Go : j'ai mes versions lossless sur mes durs internes plus une sauvegarde sur durs externes. Je vais être obligé de gaspiller la moitié du dur du TViX avec des MP3 (le reste va servir à des DVD rippés), alors que s'il lisait un format lossless, les CD que je vais y mettre seraient mon back-up. Même chose si je m'achète un baladeur de 40 Go, puisque ces 40 Go de MP3 ne me dispenseront pas de devoir garder 2 exemplaires de tous mes fichiers lossless afin d'éviter de recommencer tous mes rips si j'ai un crash de dur. C'est donc 100% de place de gaspillée.
 
Par contre, je crois être d'accord avec l'argument de Zurman sur la durée de vie de la batterie. Mais est-ce qu'un codec comme Flac ou Wavpack est si exigeant que ça par rapport à du Lame VBR ou du MPC ? Pour les accès durs, je comprends pas bien. En quoi y-a-til plus d'accès disque sur du lossless ? Parce que le fichier est plus lourd, donc occupe plus de clusters ? C'est ça ?

(dans l'hypothèse où on a plus de 100 albums, ce qui est le cas de beaucoup je crois)
 
Enfin, bon je trouverais quand même "triste" de ne pouvoir mettre que 100 albums alors qu'on a 40Go sur le baladeur.
 
Plutot que de faire des transferts réguliers entre son PC et le baladeur, ce qui représente aussi une perte de temps. Je ferais une transcodage une fois pour toute et mettrais tout ce qui est lossy sur le baladeur en gardant ce qui est lossless (+éventuel back-up) sur le PC en me passant de back-up des pistes lossy. Au pire cas, en cas de perte des données du baladeur, on est reparti pour une nuit de transcodage que le PC assumera seul (et non une nouvelle série de rips).

exactement

bha oui, tu a beaucoup plus de donees a lire sur le disque

Ca fait quand même presque 5 Go sur un dur de 120 Go, soit une quinzaine d'albums... C'est pas négligeable je trouve
 
Sans compter que sur un DVD on se retrouve parfois avec 50 Mo en trop... (mais ca reste bcp moins problématique que pour les CD)

si on continue ton raisonnement, c'est l'optifrog qui gagne puisque de mémoire, c'est lui qui compresse le plus
perso j'hésite en tout cas à passer en WV. je continue mes tests

Tu peux regagner un peu de place avec le preset -x(N). Après, l'importance de la perte est très relative. Dans l'absolu, au prix du Go, c'est négligeable, quelques euros au plus. Mais si ça t'oblige à racheter un nouveau dur, bien sûr, ça change tout, puisque ces quelques Go supplémentaires vont t'obliger à débourser 100 ou 150 euros. Ca dépend des cas, quoi. Si je passe au WP, c'est comme je le disais parce que j'ai maintenant largement assez de place, donc 15 Go de plus ou moins, ça ne change rien pour moi. Tandis que le temps gagné sur le transcodage, quel bonheur. Et puis le seek hyper-speed, aussi, comme le disait Guru. Ca, ça change par rapport à MA.

si quelqu'un à la ligne de commande cencée compresser au maximum, je suis preneur pour faire un test

-hx6
 
La doc est là : http://wavpack.com/wavpack_doc.htm. D'après celle-ci, 1 compresse plus que 6 ("optional n = 1-6 for more/less" ), mais d'après ce que j'ai vu pour l'instant, c'est le contraire.   C'est lui qui s'est gouré ou c'est moi qui débloque ?
 
Gaffe : avec -hx6, tu vas passer la nuit à encoder 5 CD !  

encodage en cours sur les mêmes 114 morceaux (à demain   )
edit : vu la lenteur je vais plutot lancer ça cette nuit

 
Il n'y a pas tant raisons qui peuvent expliquer cette migration. Monkey's Audio ne m'a jamais déçu - et j'y suis toujours revenu après avoir essayé de me tourner vers d'autres formats (flac entre autres). WavPack 4 me tentait pour sa vitesse de décompression, qui m'est surtout appréciable lorsque j'ouvre de gros fichiers sous un éditeur (CoolEdit / Audition), afin de réaliser des extraits accompagnants les tests ABX. J'ai donc commencé à convertir les gros fichiers (> 100.000 MB) sous ce format. Puis, vraiment satisfait par les changements en termes de seeking (vraiment immédiat, contrairement à MAC et Flac, juste "rapides" ), je me suis pris au jeu de la reconversion massive.
Je ne sais pas combien de place j'ai perdu dans l'opération. Je sais qu'un passage par flac m'aurait pris 5 à 6% d'espace supplémentaire par rapport à MAC -normal, et que WavPack -fx5 se situe entre les deux. Sur 250 GB de données, cela fait donc 7...10 GB d'espace perdu, pour une vitesse de décodage triplant quasiment (x15 -> x40 environ).
 

Ma reconversion massive m'aura permis de constater qu'aucun fichier MAC (dont un gros tiers encodé en 3.99) n'a souffert de corruption. Pourtant, c'est pas faute de les alourdir de tags
 

 
-fx5 me permet de gagner près d'un pour cent (12 kbps) sans concession en matière de vitesse de décodage. C'est le principe du mode asymétrique - et son intérêt premier. Le mode -normal est plus efficace, mais c'est au prix d'une complexité accrue, et par conséquent d'une vitesse de décodage plus lente (mais toujours rapide).
 
Si des personnes sont intéressées par les ratios obtenus entre wavpack -f, -fx5, flac -5, flac -8, MAC fast & normal, la feuille Excel suivante pourra permettre d'avoir quelques élements:
http://www.foobar2000.net/divers/comparison.xls
 

HAL> si tu cherches une compression maximale, inutile de t'orienter vers wavpack. Si tu veux comparer sur des bases équitables les formats, il faut les opposer à complexité égale. Par exemple, sur mon PC, WV4 -defaut est 50% plus rapide à décompresser que MAC 3.99 fast. La comparaison est déjà inéquitable si la vitesse de décompression est un critère de choix.
 
D'après mon expérience (limitée), le mode asymétrique -xn) de wavpack offre des résultats mitigés avec le mode par défaut et le mode 'high'. Avec le mode -fast par contre, le gain est appréciable (je gagne l'équivalent du passage entre MAC -fast et MAC -normal, sans aucune perte en terme de vitesse de décompression !) entre -f et -fx5 (-x6 est strictement identique en sortie à -x5 quel que soit le fichier que j'ai pu tester).
Entre -h et -hx6, je crains fort que tu ne gagnes grand chose : 3 à 4 kbps max je pense, pour une vitesse effroyablement lente. En outre, la vitesse de décodage est assez mitigée : x13 je crois sur mon Duron, soit autant que MAC -normal, qui compresse au moins aussi bien, et 150 fois plus vite que -hx6.
En d'autres termes, wavpack me semble hyper-intéressant dès lors que l'on souhaite une vitesse de décodage très élevée (sans se soucier du temps d'encodage, qui n'a lieu qu'une fois), mais l'est nettement moins lorsqu'on souhaite des ratios comparables à MAC -normal ou -high. Monkey's reste alors à mon sens le plus intéressant.

Qu'en est-il des tags pour WavPack ? Leur standard permet-il les champs personnalisables ? Sont-il placés en début de fichier (taggage très lent car padding nécessaire, cas de FLAC par ex.) ou à la fin (type APEv2)?
 

APEv2, mais aussi ID3v1 sont supportés par les composants de winamp et de foobar2000. Les champs perso sont donc réalisables (sinon je n'aurais pas un seul fichier sous ce format) et les tags sont situés en fin de fichier (idem, sinon je me serais tourné vers autre chose).

Merci pour l'info, je ne l'ai pas trouvé sur la frontpage de wavpack.com ni dans le user manual. Mais c'est vrai sachant que tu te sers de WavPack, j'aurai pu deviner.
 
Suite aux problèmes de fichiers corrompus avec Monkey 3.99 raportés sur HA (je n'en ai jamais eu moi-même), je suis resté à Monkey 3.97. Wavpack supportant le checksum MD5, et par ailleur RG avec le plug-in Winamp, est assez tentant.
 
Je teste.

Attention : le calcul md5 utilisé par WavPack est différent de celui que l'on trouve pour Monkey's Audio.
Ce dernier calcule le checksum du flux compressé (en gros, le fichier sans les tags), alors que WavPack comme OptimFrog calculent celui du flux PCM. La différence ?
- une vérification des fichiers .ape est réalisable sans aucune décompression, puisque seules les données du disque dur sont analysées. La vitesse de vérification dépend donc pour l'essentiel de la vitesse du DD et de son degré de défragmentation - pas du CPU => c'est donc très rapide.
 
- la vérification md5 des .wv et .ofr nécessite une décompression préalable du fichier, qui peut être très longue (optimfrog p.ex.) car elle dépend du mode de compression utilisé ainsi que de la puissance du CPU.
 
J'ai demandé à David Bryant d'implémenter un mode md5 comparable à celui de Monkey, très pratique pour les machines peu puissantes. Je n'ai apparement pas su trouver les bons arguments

je cherchais juste à tester ce format. D'ailleur j'ai arrêté mon test sur le parammètre -hx6 car vraiment trop lent pour un gain ridicule au vue de l'effort
J'hésite également a abandonner l'APE à cause de sa lenteur au décodage. Je teste également la "résistance" aux erreurs en cas de fichier corrompu et pour l'instant Wavpack est meilleur. L'APE fait un blanc de plusieurs secondes en APE insane là ou le wavpack fait un "glitch"

Quel mode d'encodage utilises-tu avec Monkey's Audio ?  
Sinon, as-tu déjà testé la résistance aux erreurs de Flac ? J'ai essayé une fois, et curieusement, la lecture s'interrompait, sans aller au-delà de la portion délibéremment corrompue. C'est étrange, car flac étant streamable, il doit justement offrir cette possibilité de faire fi des erreurs. C'est d'ailleurs un de ses avantages théoriques sur Monkey, qui lui devrait ne pas pouvoir enchaîner la lecture, mais qui y arrive bien (du moins avec Winamp et fb2k).
Tu confirmes pour flac ?

monkey's audio : insane
pour le Flac j'ai un résultat similaire au wavpack avec un très léger avantage à ce denier pour la longueure du glitch
Foobar renvoie alors l'erreur suivante :
ERROR (foo_flac) : FLAC__STREAM_DECODER_SEARCH_FOR_FRAME_SYNC
 
tu as peut être changé une partie plus sensible du fichier

Sans doute. Je n'ai guère eu le temps de tester cela en détail  .
 
Tu auras du mal à retrouver les mêmes ratios avec WavPack, TTA & Cie si tu abandonnes MAC -c5000 ! Tu parvenais à obtenir une lecture gapless ? Sur mon Duron 800 et la version 3.99 de Monkey, la lecture des encodages effectués en -extrahigh (-c4000) et -insane (-c5000) nécessite quelques secondes d'initialisation (donc de latence entre le double click de lecture ou le passage à la piste suivante).

pas de gapless non plus (sur un Athlon XP2400+) j'ai environ 1s de latence

As-tu essayé Monkey à profils plus légers ? Notamment pour les erreurs, je ne pense pas que tu retrouveras un blanc de plusieurs secondes. Sur l'essai que j'avais tenté avec un encodage fast (ou normal ?), la partie manquante n'était guère plus longue que celle qui faisait défaut à l'encodage wavpack.
 
P.S. Pour la corruption des fichiers, je suppose que tu utilises également un éditeur hexadécimal ?

j'utilise en effet un éditeur hexa
pour l'APE la longueure du blanc dépend du profil, d'un glitch en fast à plusieurs secondes en insane.
j'ai testé l'APE et tous ces preset. j'ai choisi l'insane car la vitesse d'encodage reste viable pour moi et que je me sers de l'APE uniquement en archivage. Pour les morceaux que j'écoute j'avais le FLAC, j'ai le wavpack maintenant ainsi que le mpc