Reprise du message précédent :

Le forward ou back de 5s peut être utilisé avec une télécommande pour avancer ou reculer dans une piste. Avec Monkey, le seek n'était pas assez rapide pour contrôler cette "navigation".  
Pragmatiquement, en appuyant en continu sur forward par ex., j'allais toujours trop loin ou pas assez. Avec WavPack, la "série de seek" débute dès que j'appuie et cesse immédiatement dès que je relâche.
 

3.97 High pour la plupart (certains albums en Normal)
 

Laptop PIII 1GHz, DD externe FireWire contenant les *.ape source et les *.wv générés. Mon disque étant assez encombré, je lançais ~30 albums chaque soir, pour ~15/17 heures de boulot non-stop.

on a ecrit un Filtre dshow si ça vous branche
http://coretta.corecodec.org/
 
la famille des core

Bonne initiative ! Tiens, vous voulez pas faire un filtre chais-pas-quoi pour lire du Wavpack sous Linux avec XMMS et consorts ? Pas que je sois concerné, mais vu le nombre de gens qui font le choix d'un codec parce qu'il pourra au cas où être lu sous Linux (Linux, c'est comme la gym ou les régimes, on compte toujours s'y mettre demain ), ça aiderait cet excellent codec à sortir de sa relative obscurité.

en theorie, pas besoin de le recalculer, si ?

Effectivement non. Les valeurs RG recalculée avec les fichiers wv sont d'ailleurs identiques à celles des fichiers ape (encore heureux d'ailleurs   ).  
Une fois n'est pas coutume, c'est foobar le coupable : il reporte bien tous les tags (c'est déjà très bien), mais pas les infos RG. Ou alors c'est moi le coupable, je ne sais pas comment l'y forcer.

ach, domage. Probleme jamais aborde sur HA ?

Il me semble que le module d'encodage CLI ne reporte jamais les données RG, car il pourrait les reporter à des encodages lossy, pour lesquels les valeurs RG seraient nécessairement différentes.
 
Sinon, je crois que dBPowerAmp reporte la valeur RG. Par contre, le soft est toujours aussi peu paramétrable (à moins d'utiliser l'encodeur CLI).

Clairement il faudrait que ca soit une option qui, comme le dithering peut ne s'appliquer qu'au lossy, puisse s'appliquer au lossless seulement.

Ce serait bien en effet.

La page de kurtnoise est non accessible ou c'est juste moi?
http://atlas2.tgv.net/~media-video [...] php?t=5412

Idem chez moi.  

Slt,
 
Le serveur d'unité-vidéo est cassé...donc plus d'accès à la base de données pour l'instant. Par contre, je peux proposer la doc en téléchargement (version pdf).
 
Un truc à lire si vous ne savez pas quoi faire...

 
tu as corecodec pour t'heberger hein  

J'ai vu ça aujourd'hui et me suis demandé qu'en penser. L'idée me paraît bonne, et dans le principe tout affinement d'une méthodologie est forcément positif, mais je vois deux raisons qui font que ça me paraît un peu vain :
 
* Le taux de compression n'est plus si important et va l'être de moins en moins. Tout en restant un critère majeur, des différences de 1 ou 2%, voire plus, sont aujourd'hui souvent mises au second plan, derrière des fonctionnalités diverses. On en est quand même aux durs de 250 Go à 130 €, et les besoins de l'utilisateur qui rippe ses propres CD ne sont pas exponentiels.
 
* Si l'on veut vraiment avoir un taux de compression le plus précis possible, il est alors plus utile de se tourner vers des tests faits sur le même type de musique que celui que l'on écoute majoritairement. Même si beaucoup de gens aiment dire qu'ils "écoutent de tout", en pratique on constate que cela veut presque toujours dire par exemple "j'écoute du métal 99% du temps, mais j'ai aussi 3 CD d'autre chose qui traînent dans un coin". En ce sens, je pense que des tests spécialisés comme celui que Guru a fait avec le classique sont plus utiles pour se représenter le taux que l'on obtiendra.
 
On me dira que rien n'empêche d'appliquer la méthodologie "échantillons de tracks" à un genre précis, et c'est vrai. Mais je reste quand même un peu dubitatif.    

J'aime beaucoup l'idée proposée par mac, mais comme d'autres, j'émets les mêmes réserves sur le champ d'application proposée, à savoir déterminer LE ratio moyen d'un encodeur à un profil donné.
 
Lorsque j'envisageai de changer de format lossless, et que je testais Wavpack 4, j'avais conscience que les chiffres obtenus en accumulant les encodages de disques restaient imparfaits. Car même après 50 disques, les avantages accumulés par un encodeur pouvaient avoir fondu cinq disques après. Un outil capable de générer des milliers courts extraits choisis aléatoirement dans une vaste librairie de fichiers permettrait d'obtenir des données plus fiables, et de mieux évaluer les conséquences en espace d'un changement de format.
 
Pour les comparaisons "publiques", comme celles de Speek, Hans Heijden ou la mienne, l'utilité d'un tel outil est par contre sujet à caution. Speek et Hans ont chacun cherché à varier la nature des genres musicaux représentés. Admettons qu'ils aient pu bénéficier d'un tel outil d'analyse : les chiffres auraient été plus précis ? Rien de moins certains, car le ratio moyen aurait été calculé sur une bibliothèque sans doute moins équilibrée que celle (limitée certes) constituée en fonction des choix rationnels d'un testeur visant une répartition harmonieuse des genres représentés. Rares sont ceux qui ont une bibliothèque composé à 10% de rock, 10% de jazz, 10% de musique électronique... Un ou deux genres dominent généralement, et l'outil de création aléatoire d'échantillons reproduirait à son tour le déséquilibre de la bibliothèque.
 
En limitant mon propre test à la musique "classique", je n'éviterais pas davantage l'écueil énoncé plus haut. Ma bibliothèque est-elle composée à 60% de musique baroque, dont la compressibilité est moindre que les oeuvres correspondant à la période romantique, elle même supérieure aux chiffres obtenus avec la création contemporaine ? L'outil statistique créera sans doute 60% d'échantillons de musique baroque, surévaluant ainsi les chiffres par rapport à ceux d'une bibliothèque d'un passionné du XXème siècle.
 
 
L'outil décrit par mac est pratique, mais plus dans le cadre d'une utilisation personnelle : que puis-je espérer comme gain en espace en passant à un profil d'un niveau supérieur ? Combien vais-je perdre en espace en passant de Monkey à Flac ? Quel est l'apport de ce mode asymétrique ? Pour ce genre de questions, un tel outil serait vraiment précieux.

plugin wavpack pour xmms en beta test ....  

UV étant de nouveau opérationnel, l'aperçu des différents formats lossless est de nouveau accessible. Vous pouvez mettre à jour vos bookmark.
 
Au passage,
    * Il y a possibilité d'avoir du FLAC dans son iPod maintenant, via iPodLinux et le MPD. (Devrait fonctionner sous Windows aussi... Si quelqu'un veut tester pour voir se que ça donne...).
    * Un plugin pour la lecture/décodage via XMMS pour le format wavpack sous Linux est désormais disponible comme je l'ai dit précédemment.
    * Le format Wavpack est en passe d'être parfaitement intégré au conteneur Matroska (le mux se fait bien, mais pas de décodage/lecture).
    * Un plugin pour GSTreamer permet maintenant de lire convenablement le format TTA, qu'il soit ou non inclus dans du Matroska.
    * Speek a fait une mise à jour de ses tests à la fin de l'année dernière.

Je pense que pour wavepack tu devrais faire mention de wapet.exe (de la même manière que tu l'as fait pour OptimFROG) qui permet de se dispenser d'utiliser un programme externe après l'extraction pour les tags.
http://www.saunalahti.fi/cse/EAC/

mouais...ça peut se faire.

Plus besoin de wapet avec la dernière beta de wavpack :  
 
http://www.hydrogenaudio.org/forum [...] t&p=251282

Libération de CASPL 1.1.2  
 
http://www.hydrogenaudio.org/forum [...] =31273&hl=

Salut,
 
Guru, je viens de voir que tu avais fait la maj concernant tes comparaisons :

 
T'aurais encore sous la main les précédents résultats concernant iTunes ?
 
 
Sinon, faudrait que tu mettes à jour les liens qui renvoit sur UV. Désolé...

De mémoire:
encodage: x11 -> x16
décodage: x24 -> x32
 
Sachant que les chiffres devraient logiquement être majorés, puisqu'il m'est impossible de tester l'encodeur dans des conditions optimales (à savoir : mise en tampon, décodage virtuel, etc...).

salut,
 
j'entre dans le monde du loseless pour ecouter mes cds (qui resteront au salon) sur l'ordi.
 
J'ai dc testé flac + foobar.
Très impressionné par les qualités audio de foobar mais un peu déçu par flac car sur 2 morceaux, des differences flagrantes de qualites apparaissent :
 
- guitare acoustique :  
foobar > winamp avec wav
foobar > winamp avec flac
flac == wav sur foobar
 
- choeurs / classsique
flac < wav
 
j'ai utilisé cdex pour extraire le wav, et flac frontend pour encoder en flac compression 8
 
j'ai pas encore essayé monkey audio...
 
voilà, si vous avez des idées pour profiter d'un très bon son, merci

Loss ca veux dire perte, et less est un privatif...
 
Si tu a une difference a l'ecoute entre un wav et sa compression flac, c'est que tu a une difference dans la lecture. Utilise tu le meme soft de lecture, avec les meme parametres (replaygain, DSP, dithering, volume...) ?

Puisque tu utilises foobar2000, as-tu fait:
- un test ABX?
- une comparaison avec bitcompare?

ENCODEURS LOSSLESS: décodeur ALAC "open source" disponible
 
Depuis un an environ, Apple a rendu l'iPod et iTunes compatible avec un format lossless. Ce format présentait pour inconvéniant d'être propriétaire : impossible de l'utiliser ailleurs que sur les produits Apple (exit Winamp, foobar2000, WMP...).
Un petit crack de l'info nommé David Hammerton est parvenu à mettre au clair les arcanes du format, et vient de présenter un décodeur open-source :
 
http://www.hydrogenaudio.org/forum [...] opic=32111
 
 
Cette nouvelle pourrait bouleverser la donne en matière d'utilisation de formats lossless, puisqu'il devient possible à quiconque d'utiliser ALAC plutôt que Flac, Monkey's Audio ou WavPack, d'en profiter sur ses logiciels habituels ainsi que sur les solutions mises en place par Apple : iPod, iPod mini, AirPort.
 
Reste à attendre le développement de plug-in pour d'autres logiciels

Plutot une bonne nouvelle ca

Quelques précisions sur "l'open sourcitude" ( ) de la chose?

 
(la mise en gras est de moi)
http://craz.net/programs/itunes/alac.html
 
Maintenant, cette licence s'applique uniquement au programme, pas au FORMAT en lui-même, qui est semble-t-il une propriété exclusive d'Apple.
 
Ce qu'il convient de noter, c'est qu'il devient possible à quiconque de doué et s'emmerdant les week-end de développer un encodeur alternatif, ouvrant la possibilité d'encodages plus efficients ou plus rapides par exemple.

OK, c'est comme VLC qui fait de l'open source avec (entre autre) du Real et du Quicktime.  
 
On "cracke" (je sais, ce n'est pas joli comme terme) en partie un logiciel fermé - si pourri soit-il, c'est vrai - et on en tire du code qu'on rend disponible et voilà de l'open source.  

C'est de l'open source au sens strict : les entrailles du code sont ouvertes au regard. Pour beaucoup, c'est suffisant, puisque très peu se soucient véritablement des problèmes de légalité (y compris les linuxiens/vorbisiens, qui considèrent avec une systématicité quasi-mécanique comme troll tout argument expliquant que tel ou tel partie du logiciel dit "Open" utilise abusivement des technologies brevetées. Fin de la parenthèse).

Finalement ça doit être ça la liberté.    
 
Enfin bon, fermons la parenthèse.

je rapelle que la norme mpeg4 contient elle aussi un format lossless. si un lossless doit s'imposer à mon humble avis ce sera celui là. par contre la norme vient d'être terminée, donc les codec sont à venir

Pas trop tôt...
Je suis impatient de voir arriver un codec sous ce format, pour voir ce qu'il a dans le ventre (par rapport à Lpac p.ex. qui a servi de référence).

Que faut-il en attendre? De meilleurs ratios de compression?

Mais ci c'est du reverse engineering (et pas un crack ou assimilé), alors il n'y a pas de problème, c'est parfaitement légal.
 
reverse engineering: on dispose du produit à reproduire, on lui donne des entrées (ici des fichiers audio éventuellement crées de toutes pièces), il donne des sorties (fichiers alac). Ensuite on étudie les sorties en fonctions des entrées et on essaye de faire la même chose.

Tant mieux alors.