Reprise du message précédent :

Oui, exactement.

Bonne question. Pas dans un tag Vorbis, en tout cas. Mais c'est du metadata, oui...
 
Au moment où tu encodes, tu peux aussi utiliser --verify pour être sûr que ton FLAC est identique à ton wave. Ca peut te permettre de t'apercevoir que tu as une barrette de RAM ou ton disque dur qui déconnent. Vu que FLAC est lossless et que si la fonction --verify renvoie une erreur, c'est qu'il y a un bug sur ta bécane.

 
Le WavPack s'impose de fait, car il est open source, ouvert ET performant.
 
Le TAK et le Monkey Audio n'ont pas ces avantages... Y'a deja des lecteurs audio qui lisent le WavPack par ex.

Le FLAC est tout aussi libre et ses performances sont à peu près identiques dans le contexte de 2009. Quand à Monkey's Audio, il est lui aussi open source depuis belle lurette, contrairement aux affirmations récurrentes sur le sujet. Son problème, c'est d'être symétrique, donc de demander autant de temps de décodage que d'encodage.
 
Pour info, le format de tags de WavPack est l'apeV2, c'est-à-dire... celui créé par et pour Monkey's Audio.  

Depuis des années, même. Encore heureux. A moins que tu parles de Linux, qui a toujours 3 guerres de retard sur Windows en matière de lecteurs audio. Mais même sous Nunux, il me semble bien que le Wavpack est lisible depuis longtemps. Par contre, lire ses tags, c'est sans doute une autre histoire. M'enfin c'est le même problème avec les tags Vorbis.

Nan, faut pas être mauvaise langue comme ça... J'ai jamais eu de problème de lecture de tags avec WavPack sous linux.
 
Pour en revenir à ce qui a été dit, siFlac a un avantage, c'est bien d'avoir un support hardware plus développé.
 
Et sinon, certains gourous n'aiment pas WavPack à cause de sa license BSD (en gros tu prends le code, tu en fais ce que tu veux sans rendre de compte, y compris te faire des sous avec ou l'inclure dans un programme pas libre).

L'important c'est que le code soit libre, donc que le support soit large.
 
Après pour moi y'a une ENORME différence entre WavPack et FLAC quand meme...
 
Sinon a ce train là on peut prendre aussi prendre du Apple Lossless si le ratio a ZERO importance.

Comme on l'a déjà dit, pour le code libre, c'est les cas ET DE FLAC ET DE WAVPACK.
Les deux sont sous licences libres.
 
Ma remarque dans le post précédent, c'est juste pour dire que la license libre BSD n'est pas appréciée de tous (perso, pour moi c'est pas bien grave, hein). Mais le code est bien libre que ce soit Flac ou WavPack
 

Je vois pas où il est le fossé, sinon il faut approfondir là.

Tant que les lecteurs Linux ne seront pas foutus de respecter les specs Vorbis et donc de lire l'intégralité des tags, je continuerai d'être mauvaise langue avec ces gens qui réclament du code ouvert et n'en font ensuite rien du tout.    
 
Bon, blague à part, on est revenus au point de départ. Peut-être l'occasion de rappeler ou faire découvrir ce tableau : Lossless comparison.
 
On y voit clairement que FLAC et WavPack sont désormais au coude à coude devant les autres. Même s'il faut tempérer selon son usage (perso, je n'ai pas l'utilité du 10ème des fonctionnalités notées). Ce que je préfère chez WavPack :
 
- Il compresse un chouia mieux (mais ça a de moins en moins d'importance, vu le faible écart).
- Les tags sont en fin de fichier donc pas besoin de padding.
- On gagne deux lettres pour le nom de fichier par rapport à FLAC (je rigole, mais je dépasse très largement les 200 caractères pour certains morceaux ).
- Le développeur est un homme charmant (alors que celui de FLAC doit être le frère de celui de Foobar...   ).
 

Y'a plus d'écart entre FLAC au taquet et WavPack qu'entre WavPack et Monkey Audio (bah oui si tu utilises pas les meilleurs switch pour WavPack aussi...). FLAC est quasi le plus mauvais encodeur lossless qui soit encore développé et utilisable.
Et je parle pas du mode "MONO" de WavPack qui tant a amélioré un poil la compression sur les vrai sources mono (vieux CD).
 
Et en plus contrairement a certains concurent: MPEG-4 ALS/SLS (vu que c'est en fait la même chose de fait), WavPack, il n'as non plus de mode hybrique...
 
Defendre le FLAC pour une utilisation PC est un peu ennuyeux dans le sens ou WavPack fait mieux quasi partout...

Sauf qu'en pratique il n'y a pas forcément de rapport de cause à effet. Sinon, depuis le temps que l'ogg Vorbis existe, il aurait largement supplanté le MP3.  
 
D'ailleurs, le simple fait que tu penses comme beaucoup que Monkey's Audio est propriétaire alors qu'il est libre depuis des années montre bien qu'être libre ne signifie pas pour autant être supporté.
 

1% de différence sur le taux de compression, pour toi c'est "ENORME" ?
 
Tiens, on va le dire autrement : sur un dur où tu as stocké 500 CD en FLAC (et je doute que grand monde ait autant de CD), tu en mettras 505 en WavPack. Punaise, c'est énorme, comme différence...

Je suis en WavePack aussi, mais je risque bien de bouger vers FLAC pour cette raison. Finalement j'en ai un peu marre de transcoder en aac pour les lecteurs "non-PC" (autoradio, dd mutlimedia...), la taille des supports commence a supporter le lossless directement donc bon...

D'un côté y'a quasi aucun autoradio ou lecteur MP3 qui lit le FLAC non plus... A la rigueur on a plus de chance avec l'Apple Lossless dans ce cas.

En même temps, j'utilise que WavPack moi aussi.  
Parce que le concepteur vient de San Francisco...    
 
Oui WavPack est mieux partout que FLAC, mais pas au point d'utiliser le terme ENORME pour qualifier les différences, amha.  
 

D'ailleurs, c'est surtout quand il s'agit du support hardware qu'on trouve des avantages à FLAC.

Puisqu'il y a eu croisement de posts, quand je parle d'avantage pour FLAC concernant le support hardware par rapport à WavPack, je vois bien ça comme comparer "pas grand chose" et "presque rien".

 
Sur un CD pris au hasard, Caravan Palace :
 
WAV : 580 062 660 octets
FLAC -8 : 396 450 135 octets (soit 1:1.463 ou 68,35%)
WavPack --hhx6 -m : 388 188 228 octets (soit 1:1.494 ou 66,92%)
 
Ecart donc de 1,43%, sachant que j'ai des Tags et le MD5 dans le WavPack et pas dans le FLAC ce qui ne l'aide pas... (certes ça doit jouer a 0,01% )
 
Et c'est plutôt un mauvais exemple, car j'ai des CD plus calmes qui montrait des ecart plus vers les 3,5%. Pourquoi ce priver d'autant de compression supplémentaire ? D'autant plus que le tag des cover et le cue sheet est intégré au format. (certe peu de support pour le moment mais bon )

Entre FLAC -8 et WavPack -hhx3, on monte à 1,10% ou 1,20% de différence. C'est-à-dire peanuts. Après, tu peux toujours jouer avec -hhx6, pour rogner quelques kilobytes supplémentaires, mais ça devient un peu naouak.

Si le seul critère pour toi est le taux de compression...
 
Au passage, et c'est une vraie question : ALAC compresse moins que FLAC ?
 
Et au passage encore : si FLAC n'a pas connu d'améliorations vraiment notables en matière de taux de compression, c'est peut-être parce que bien qu'open source et répandu sur toutes les plate-formes, personne n'a contribué au projet depuis le début en dehors de son créateur. C'est ça aussi l'open source : le travail collaboratif tout seul pendant toute sa vie.  

Le mode mono de WavPack l'a seulement remis à niveau vis-à-vis de FLAC dans ce domaine. Parce que sur les enregistrements mono, WavPack compressait nettement moins que FLAC. J'ai été le premier à le signaler à David sur HA après avoir fait une batterie de tests (mais Guru lui avait signalé le fait par MP quelques semaines avant, donc j'ai seulement été le deuxième utilisateur à m'en apercevoir ). Suite à ces observations, David a implémenté "--optimize-mono", avec une réticence compréhensible puisque ça faisait péter la compatibilité descendante.
 

Mais le peu de différence ne compense pas le support de FLAC, même uniquement sur PC, et même uniquement sous Windows. Je suis repassé au FLAC pendant 2 ans, par exemple, parce que CATraxx ne supportait pas WavPack. MediaMonkey peut lire le WavPack, mais pas ses tags. etc.

Au contraire : des tas le supportent. En fait, la plupart en dehors évidemment des iPods. Et pareil au salon : j'ai un TViX, il lit le FLAC. Je ne m'attends pas trop à ce qu'il lise le WavPack un jour... Je m'en fous parce que je ne l'utilise pas pour la musique, mais ça montre bien à quel point le FLAC est rentré dans les moeurs.
 
Je sympathise avec ton amour du WavPack, ce n'est pas le problème. Mais il faut quand même regarder les choses en face.  

Je crois que c'est iPod qui cache la forêt. J'ai dans mon environnement proche 3 appareils :
 
- Le TVix du salon : il lit le FLAC mais pas le WavPack
 
- L'Archos de ma fille (quand elle vient à la maison) : il lit le FLAC mais pas le WavPack
 
- L'Ipod mini de ma femme (cadeau d'entreprise) : il ne lit évidemment aucun des deux formats. Et de toute façon, avec un dur de 4 Go, je n'irais pas lui coller du lossless.  
 
J'ajouterai que si je m'achète un baladeur un jour, ce ne sera pas un iPod et il y a donc de grandes chances pour qu'il supporte le FLAC.
 

Oui, ben 1,43% (en faisant le kéké avec -hhx6 qui est totalement impraticable pour quelqu'un qui a plusieurs centaines de CD à encoder/transcoder   ), ça te fera 507 albums dans le même espace où tu mettras 500 albums en FLAC. C'est une satisfaction intellectuelle, m'enfin au-delà de ça...  

Et j'en ai vu pas mal où la différence ne dépassait pas 0,5%. J'ai fait assez de tests à une époque pour le savoir. FLAC 1.2 a quand même un peu amélioré le taux de compression, tandis que WavPack a un peu regressé après je-ne-sais-plus-quelle version. Du coup, les différences sont devenues mineures.

FLAC aussi, hein. De toute façon, je préfère éliminer mes doublons et regagner des Go en pagaille qu'utiliser les cue sheets et garder mes CD entiers. Surtout que je n'ai aucune intention de les regraver un jour donc la cue sheet... euhhhh...

 
Je sais pas combien ça devrait representé en FLAC/WavPack mais j'ai ~100Go de MP3 a reencodé, donc quelques Go c'est toujours ça... En plus, franchement vu la vitesse d'un rip de CD, avec les machines actuelles, on encode plus vite un CD en WavPack qu'on ne le decompresse... (bah ouai QuadCore toussa... )

 
voila, Et pour l'iPod, Rockbox pwouah, ou foo_dop qui transcode a la volee   Je revis depuis que j'ai benne iTunes

+1 le transcodage est possible. Avec nos dual/quad core (et jusqu'a 8 thread sur les Core i7 donc...) bah faut quand meme pas exagerer, transcoder un album WavPack->LC-AAC ca prends combien ? 2-3 minutes a tout casser...
 
Sauf si on remplit les 120Go d'un iPod Classic d'un coup, c'est pas problématique. (remarque vu les perfs d'iTunes, 120Go sans transcodage ca prends deja la nuit je pense )

Un rip c'est 5 minutes. Même avec un quadcore, tu me feras pas croire que tu encodes un CD en -hhx6 dans le même temps. Même l'auteur de WavPack ne dépasse jamais -hhx4. Et non seulement -hhx6 ne fait gagner au mieux que quelques octets, mais il peut même parfois produire des fichiers légèrement plus lourds que du -hhx5 ou -hhx4. Il n'y a guère que sur la musique électronique qu'il peut parfois faire gagner quelques Ko. C'est le preset totalement déconseillé.  
 
Au passage, si tu as un quadcore, tu dois avoir un énorme disque dur avec plein de place inutilisée.

Lapin compris. Tu vas réencoder des MP3 en WavPack ?

Je lance le RIP d'un CD pendant que j'en encode un autre avec plusieurs WavPack en //... (pas trop compliqué a réaliser)
Sinon j'ai je ne sais pas combien de CD exactement, mais je sais que ça fait 100Go sur mon serveur... Et en gros au final, ca devrait representé dans les 400 ou 500Go de WavPack a priori...
 
Sinon pour le preset, c'est totalement débit si ça peut etre moins bien que 4 ou 5, c'est une erreur de conception grave. En tout cas la doc. n'en fait pas mention...

Tu as 1500 CD que tu as pour l'instant rippés et encodés en MP3 et que tu vas de nouveau ripper et encoder en WavPack ? C'est ça ?  

Ce n'est pas une erreur de conception, ce sont des presets pour des cas très particuliers. Il te prévient qu'aller au-delà d'x2 ne sert quasiment à rien :

Il a été dit plusieurs fois sur HA que ces modes spéciaux appliqués à de la musique "normale" n'avaient aucun intérêt.
 
Tu as la même situation avec les switches FLAC ésotériques qui plaisent à quelques nerds tout contents d'avoir gagné 27 Ko sur un album (on se distrait comme on peut   ) et qui réalisent au bout d'un moment que les "flattop" et je ne sais quoi produisent l'effet inverse sur certains albums. Ce sont des presets de développeurs, à ne pas utiliser en usage courant.  

ok, j'ai vérifié les FLAC que j'avais commencé à faire sur mon HDD contenant les .WAV, j'en ai environ un défectueux par album

j'ai coché la petite case "verify" dans flac frontend.
d'ailleurs, je chercherai un truc qui puisse encoder en cherchant dans les sous-sous-sous-...-répertoires (vu que je classe par genre, artiste (et parfois catégories), année, album, CD) le truc par défaut de FLAC s'arrète au premier sous-répertoire

mais de toute façon, le disque a mourru complètement et ... il a entrainé un plantage du PC sur lequel j'avais mis un 2e disque de meme capacité (un 250 Go SATA qui trainait depuis que j'ai acheté un 1To)... en plein milieu d'une copie (ptet que c la copie qui a achevé le disque, d'ailleurs !)

et au reboot, chdksk me dit "système de fichier RAW".

alors comme ça commence à me lourder cette histoire, et que j'ai plus envie de chercher à droite et à gauche un CRC pour tester si le WAV est pas corrompu, d'attendre qu'il se copie en priant pour qu'il n'y ait pas de secteur défectueux, et le retester voir si la copie qui a duré 10 minutes pour 10 Mo de WAV s'est bien passée, j'ai tout supprimer et je vais tout refaire sur un HDD sain.
l'intéret de bidouiller sur le HDD était d'aller plus vite que de refaire les rips, mais avec le temps que prennent les copies avec le HDD qui a morflé, le rip sera sans doute pas bcp plus lent et surtout plus sur.

j'ai mes MP3 pour écouter pour le moment - et ça j'en ai plusieurs copies sur plusieurs HDD et plusieurs PC
et je referai les rips bien proprement, et directement en FLAC.

merci pour vos éclaircissements et vos commentaires en tous cas .

pour ajouter un peu d'eau au moulin de borabora dans la discussion FLAC vs wavpack - FLAC en preset 8 m'a paru plus rapide qu'un encodage MP3 (bon j'ai qu'à pas faire -q 0 dans lame aussi !), et le décodage parait aussi etre rapide et facile, ce qui peut toujours servir vu que j'ai pas un foudre de guerre en usage normal -voir config "le bon" - et que je laisse en général foobar tourner en arrière plan quand je lance un jeux - alors dédié un core ou plus de 5% de temps CPU au décodage de la musique n'est pas envisageable pour moi.

par contre, le problème avec le rip, ce n'est pas de faire 4 encodages avec 4 core, le problème c que les 4 encodages vont se géner mutuellement pour l'accès au HDD, et qu'au final ils iront un peu moins vite qu'un seul, tout en augmentant la fragmentation sur le ou les disques. problème d'autant plus important en lossless où les tailles de fichiers à écrire sont aussi très importantes, contrairement à l'encodage MP3.

de plus, la cuesheet, je m'en contrefout aussi, l'intéret de stocker au format numérique est de se débarasser du support pour plus de fléxibilité : je veux écouter des chansons dans la voiture ? hop, copier/coller sur une clé USB. je veux les écouter dans le train ? hop sur la carte mémoire de mon baladeur ou de mon téléphone. le CD n'est là que pour la license d'écoute et la sécurité de refaire un rip en cas de soucis (j'aime me remuer tout seul le couteau dans la plaie. aie .) ... quand au taux de compression, vu les tailles en jeu, meme si quelques pouillèmes de pourcents peuvent paraitre bcp dans l'absolu en poids de fichier sur une collection de 300/400 CD (tiens de re-ripper mes CD, ça me donnera l'occasion de compter !), si je voulais vraiment gagner de la place, je dois avoir des chansons en double entre mes CD, je pense gagner plus de place en supprimant les doublons qu'en utilisant un encodage extrème

le FLAC a l'air plus compatible niveau matériel - j'ai été surpris de voir que le rio karma le supportait, c un super vieil appareil !, mais c surtout que j'ai eu l'impression que la communauté autour du format avait l'air plus étendue et réactive

enfin, de ce que j'ai lu des docs, je crois que le FLAC a un comportement plus naturel que le wavpack, comme le souligne borabora, d'ailleurs : un encodage en FLAC -3 donnera une compression moins importante qu'en -6, et ainsi de suite, meme si les gains ne sont à priori pas énormes. alors que le wavpack a des options spécifiques pour certains genre spécifiques ... la bonne chose à faire (mais bon, ayant un background en informatique et des notions de programmation, je suis bien placé pour savoir que c bien plus facile à dire qu'à faire !) serait d'implémenter un algorithme de détection de ces genres spécifiques et de déclencher ces optimisations quand elles sont nécessaires, pas de devoir choisir tel ou tel switch suivant ce que tu encodes.

bizarrement, je crois que ce qui m'a décidé entre FLAC et wavpack, c que le FLAC n'est pas hybride - j'ai eu peur de foirer un switch en ligne de commande et me retrouver avec un fichier lossy sans faire gaffe, ce qui est impossible avec FLAC qui n'offre QUE du lossless.

FtY

On trouve bien plus de rip flac que wavpak sur les sites dont il est interdit de parler ici...
de là à dire que c'est mieux d'utiliser flac, il n'y a qu'un pas
 
Sinon, vous faites un CUE + un CDIMAGE.flac ou un CUE + un flac par chanson ?
Je préfère le CDIMAGE mais je ne sais pas pourquoi à part que ça fait moins de fichiers sur le disque dur.

Tu peux faire une recherche "*.wav" puis balancer la sélection dans la fenêtre. Ou utiliser à peu près n'importe quel lecteur audio pour transcoder, y compris bien sûr l'irremplaçable Foobar.

D'autant que sans cue sheet, tu auras toujours une reproduction fidèle du CD. La seule chose qui manquera, c'est le pregap silencieux de 2 secondes en début de CD et l'affichage des gaps sur un lecteur de salon.

Ah mais clair. Surtout que l'autre intérêt de benner ses doublons, c'est de garder ceux qui ont le meilleur mastering.  

Ce n'est pas vraiment la question. Comme je le disais, FLAC a aussi des modes "ésotériques", mais le développeur ne les a simplement pas mis en avant. Il y a un certain nombres d'analyses qui ne peuvent être menées par un encodeur, ne fût-ce que parce qu'elles prendraient trop de temps. De ce fait, les presets sont là pour varier les méthodes de compression puisqu'elle peuvent être optimales pour le morceaux X et au-dessous de la moyenne pour le morceau Y.
 
A noter d'ailleurs que la progression du taux de compression dans les presets FLAC n'est pas non plus linéaire. Sur un morceau en mono, les presets -0 et -3 sont catastrophiques (et là je ne parle pas de 2 ou 3% de différence), sans avertissement dans la doc. Echantillon :

10 mono CD
Total: 5 014 974 824 bytes
 
Compressed:
 
-8: 1985302030 bytes (40,17%)
-7: 1987809706 bytes (40,22%)
-6: 1989794663 bytes (40,25%)
-5: 1990929735 bytes (40,28%)
-4: 1992459767 bytes (40,31%)
-3: 3097916561 bytes (62,03%)
-2: 2089742661 bytes (42,25%)
-1: 2094052058 bytes (42,33%)
-0: 3237643894 bytes (64,82%)
 
C'est sans grande importance puisque je doute que qui que ce soit utilise un preset inférieur à -5, mais ça montre que FLAC a lui aussi ses incohérences d'échelle.   Si tu veux savoir pourquoi, cf ce topic : Strange results with Flac -0 & -3 in mono

Avec FLAC, pense éventuellement à créer du padding à l'encodage. Par défaut, il en colle 8 Ko (ou 64 Ko sur un fichier représentant plus de 20 minutes de musique). J'en mets 4 Ko seulement avec "-P 4096 " puisque c'est très largement suffisant pour des tags textuels. Par contre, si tu veux intégrer les pochettes après l'encodage, les 8 Ko par défaut seront évidemment très insuffisants et cela obligera à réécrire l'intégralité des fichiers (connerie des tags en début de fichier).

Nos posts se sont croisés, mais je vais détailler : l'image + cue sheet n'a que des inconvénients et quasiment aucun avantage (voire zéro avantage si tu ne comptes pas regraver l'image un jour).
 
- Tu es incompatible avec 90% des lecteurs.
 
- Tu gardes des tonnes de morceaux en double (inévitable à partir d'un certain nombre de CD en jazz et musique populaire) ou que tu n'écouteras jamais.
 
- Si tu as un problème au moment du rip, il faut reripper le CD entier. Et si tu as un problème de corruption ensuite sur le fichier, c'est le disque entier qui part à la poubelle.
 
- Plus moyen de chercher un morceau par le système de fichiers. Tu es obligé de passer par un lecteur audio.
 
A côté de ça, les seuls avantages éventuels sont :
 
- Préservation du pregap, c'est-à-dire... 2 secondes de silence.
 
- Préservation des index quand tu en as au sein d'un morceau. Utile uniquement pour certains amateurs de classique.
 
- Une fois regravé, le CD affichera "-2... -1..." pendant les gaps sur l'écran LCD du lecteur de salon (trop cool   ).

Merci pour tes précisions

Dans ce cas, effectivement, si tu rippes par track, tu perds les 2 secondes de silence qui figurent avant le 1er morceau du CD.  

Probablement, oui.

Euuuuh... oui, mais quel rapport avec les doublons ? Sur l'ensemble de ma discothèque, j'en ai des milliers. Je n'ai jamais fait le compte de ce que je virais, mais ça chiffre vite si tu écoutes autre chose que du classique. Rien qu'avec la dizaine de grands classiques de la soul ("Respect", "Sitting On The Dock Of The Bay", "Stand By Me", "It's A Man's Man's Man's World" etc.), je dois arriver à la centaine de doublons. J'ai des coffrets qui doublonnent pour 30%, voire plus, parce que j'ai acheté ensuite des albums de l'artiste (rien que sur mon box set Aretha Franklin, je dois avoir 70 morceaux en double suite à l'achat au fil des années de ses albums Atlantic, et je ne parle même pas du Clash, d'Al Green ou de B.B. King). Il y a aussi les albums en double parce que nouvelle version avec bonus tracks + un CD supplémentaire (genre les "Deluxe editions" d'Universal), où je préfère continuer d'écouter le mastering plus ancien pour les morceaux de l'album origine. Et puis il y a les CD de magazines (Soul Bag, Mojo, Uncut...) dont j'ai déjà souvent 1 ou 2 morceaux, et parfois même la quasi-totalité du CD (genre quand ils font une compile Chess, Motown, Stax ou autre).
 
Enfin, je sais pas, mais si on a une grosse discothèque et qu'on est assez fan de quelques artistes, on a forcément des tas de doublons.   Ca doit bien représenter chez moi 150 ou 200 CD, en rassemblant toutes ces tracks éparses. Donc 100 fois ce que je gagne en place en utilisant WavPack plutôt que FLAC.  

Aucune différence. On va le redire encore une fois puisque c'est idée reçue récurrente : ripper par track ne supprime ni ne modifie les gaps. Qu'il y ait de la musique ou pas dans le gap. La seule différence, je le répète, c'est que l'affichage LCD de ton lecteur de salon ne verra plus de gaps. Donc au lieu d'avoir :
 
- Morceau 1 = affichage de 0:0:0 à 0:3:25
- Gap          = affichage de -0:0:2 à -0:0:1
- Morceau 2 = affichage de 0:0:0 à 0:4:45
 
Tu auras (dans le cas où tu auras gravé un CD avec tes tracks)
 
- Morceau 1 = affichage de 0:0:0 à 0:3:27
- Morceau 2 = affichage de 0:0:0 à 0:4:45
 
Les 2 secondes ou plus de silence ou de musique seront toujours là, intacts, mais le lecteur ne repassera pas en compte à rebours au début du gap : il continuera le décompte du temps du morceau qui précède ce gap. Bref, à moins d'aimer surveiller la fin des morceaux pour pouvoir admirer l'affichage du lecteur qui passe en négatif pendant 2 secondes, c'est aussi utile que du poil sur un saucisson.

Tiens, juste quand j'en parlais, un posteur sur HA s'étonne de ne pouvoir lire le tag Vorbis "VERSION" sous Linux (je ne sais pas s'il utilise l'Ogg ou le FLAC, mais ça revient au même) :
 

 
Sachant que les lecteurs n'implémentent même pas les tags qui font partie du standard Vorbis depuis bientôt 10 ans, il ne faut pas espérer un support des tags customs (pourtant prévus aussi dans le standard). A ma connaissance, un seul lecteur Linux respecte les tags Vorbis. J'ai oublié son nom mais c'est celui qu'utilise HPL donc il pourra le rappeler ici.  

Plus haut c'est le support de WavPack sous Linux que j'évoquais (j'utilise QuodLibet, mais je ne crois pas que ça fait une différence).
Mais j'abonde en ton sens pour Vorbis.  
Paradoxalement (ou pas), avec ces formats libres, pour les tags il vaut mieux ne pas sortir des sentiers balisés et se contenter de remplir gentiment uniquement les cases prévues. Quand on utilise (en dual boot ou sur disque exterieur) ces fichiers audio entre Linux et un lecteur (ultra) personnalisable comme foobar2000 (au hasard), on est presque toujours plus ou moins obligé de s'adapter (voire se restreindre).

Si t'as une CUE Sheet et les WAV séparé, normalement on peut recup les pre GAP... Mais bon c'est quand meme de moins en moins vu sur les CD le pre gap donc de toutes facons...

Sur ce coup c'est foobar qui n'a pas l'air de respecter les specs des formats de fichier. Pour le WavPack par ex, y'a des specs pour les cover & co et foobar ne les mets pas dans ces champs predefini.
 
Certes les autres lecteurs ne sont pas mieux car ne supporte en general rien, mais au final, a part MP3 + ID3 v2.4 y'a pas grand chose comme tag de vraiment supporté largement.

Ouai, entre foobar2000, le lecteur audio sous Linux et le lecteur portable, j'en ai eu des maux de têtes avec ces histoires.
 
Concernant WavPack et foobar2000, j'ai aussi remarqué un petit détail: avec foobar2000, impossible de mettre les numeros de pistes en format 2 chiffres (01, 02, etc) alors qu'avec les fichiers obtenus avec EAC ou avec MP3tags pas de problème. C'est rien comme ça je sais...

C'est ce qui fait qu'au lieu de passer sous Linux, je me passe de Linux. Au moins jusqu'au jour où j'aurai les mêmes fonctions que Foobar avec un lecteur Linux.  

Il y a une autre solution pour récupérer le pregap si tu n'as pas de cue sheet :
 
1- Au moment où tu vas pour lancer la lecture de ton CD-R sur ta platine de salon, tu t'arrêtes dans ton élan.
2- Tu comptes 1... 2...
3- ... et là seulement tu appuies sur le bouton.
 
Voilà, tu as retrouvé ces indispensables 2 secondes de silence du pregap sans lesquelles ton émotion musicale à l'écoute du disque aurait été diminuée.  
 

Uh ?   D'où tu sors ça ?  

Source ? Et quand bien même, on s'en fout puisqu'aucun autre lecteur ne lit ces champs.

Si, les tags de base APEV2 ou Vorbis sont supportés. Cette même pitoyable demi-douzaine de champs qui existent depuis 15 ans.

Voilà qui est bien résumé.  
Ce jour ne risque pas d'arriver. On en a déjà discuté maintes fois, et ce depuis longtemps. Force est de constater que rien n'a changé...
 
Edit: Et puis je dirais que quand on reproche à foobar2000 ne pas faire ce qu'aucun n'autre lecteur ne sait faire, ça montre seulement qu'on a fini par ne plus attendre grand chose des autres lecteurs.

 
Perso je blaire pas foobar2000 car ce qu'il manque d'essentiel c'est une interface userfriendly. Comme quoi

Faut passer sous Linux alors.
(Pas taper, c'est pour rire)

C'est clair.   En même temps, j'utilise peu de composants Foobar, et assez peu de fonctionnalités (du moins qui ne pourraient être remplacées par un autre soft complémentaire). Il ne manquerait finalement pas grand chose pour que je switche : c'est surtout cette absence de gestion complète des tags Vorbis ou APEV2 qui m'empêche d'aller vers un autre lecteur, quelle que soit la plate-forme. Je pourrais même faire avec un lecteur basique sous Linux si à côté de ça il y avait l'équivalent d'un CATraxx. Mais c'est le même scénrio sous Linux avec les gestionnaires de discothèque : rien ou tout pourri.

On peut difficilement faire plus user-friendly que Foobar avec l'interface par défaut qui imite celle d'iTunes et de presque tous les lecteurs du marché. M'enfin bon...
 
A part ça, tu réponds jamais aux questions qu'on te pose ?

serieux lance winamp ou itunes derniere version deja t'a une interface mono fenetre et bon c'est limissible quoi.
 
tu cherches pas pendant 5 minutes chaque fonctionnalité.

Lance Foobar et il va te demander quel type d'interface tu veux, y compris mono-fenêtre si ça te chante. Après, si tu te bases sur des screenshots de configs archi-customisées à l'aide de 43 plugins, évidemment...

En fait, tu ne les cherches même pas, tu sais qu'il n'y en a aucune.    
 
A part ça, tu réponds jamais aux questions qu'on te pose ?

Bon en a déjà parlé, mais ça n'a pas changé. Le problème est que les lecteurs audio sous Linux (pour une énorme majorité) sont conçu d'abord comme des interfaces pour GStreamer (le plus souvent) ou Xine. Et de toute façon, la demande des utilisateurs est souvent ailleurs (un plugin Wikipedia, une recherche de pochettes, une interface à la iTunes...).
 
Sinon, j'ai jamais pu blairer ces lecteurs où il y a affiché systématiquement 200 fois sur la même colonne "The Beatles".