Reprise du message précédent :
Langoustator & gURuBoOleZZ : merci pour ces réponses.  
 
J'ai une autre question qui vient de surgir entre-temps. J'ai encodé un CD via Foobar, avec mise en tampon complète (j'ai 1 Go de RAM) et obtenu ce résultat : 44,82". Par une sorte de scrupule paranoïaque (je veux pas faire d'erreurs, ce coup-ci ), j'ai refait l'encodage en ligne de commande, après un reboot. J'obtiens  cette fois un temps d'encodage de 30,28".
 
La seule explication qui me vient à l'esprit est que Foobar inclut le temps de mise en buffer du fichier dans le temps d'encodage. Mais si c'est le cas, cela fausse complètement les temps et s'avère beaucoup moins précis encore qu'un encodage en ligne de commande sans mise en tampon. Où me trompe-je ?  
 
Précisions :
* PIV 3,06 Ghz, 1 Go de RAM
* Fichiers source Wav et fichiers compressés sur 2 disques différents défragmentés, chacun seul sur son port.
* Système et fichier d'échange sur un 3ème disque, lui aussi sur son port (j'ai 2 ports ATA et 2 ports SATA, ce qui permet ce montage idéal avec mes 3 disques et mon lecteur).
* Priorité donnée à Foobar : "realtime" (le maxi)

La mise en tampon n'est pas comprise dans le calcul du temps d'encodage. J'en suis quasiment certain - mais j'ai cependant quelques doutes. Il y a un moyen assez simple de vérifier cela : c'est de placer le fichier source sur un média très lent (sur une clé USB par exemple, il peut s'écouler une grosse minute pour que la mise en tampon s'effectue ; l'impact sur la vitesse serait alors simple à mettre en évidence). Je ne peux pas le faire actuellement.
 
La mise en tampon doit par ailleurs s'accompagner d'une priorité à l'encodage > à la normale. Pour accroître la pertinence, rien ne t'empêche de lancer deux ou trois encodages successifs et de faire la moyenne (ou de retenir la valeur la plus flatteuse).
 
En ce qui me concerne, j'effectue mes tests après reboot et suppression du maximum de tâche de fond que liste le task manager d'XP. Je ne veux que foobar2000 et moi.

Bon, j'ai trouvé une 1ère erreur, tellement grossière que je crois que je ferais mieux d'aller faire une bonne nuit avant de continuer. J'avais pensé à mettre à jour la dll Wavpack dans les composants Foobar, mais j'avais laissé une 4.2 beta de l'executable à la racine. Oui, j'ai honte.
 
Ca me donne maintenant 40,64" sans buffer et 38,29" avec, deux scores très proches avec avantage logique à celui avec buffer (je me suis dit que tant qu'à faire, autant tester avec et sans). J'ai néanmoins encore un écart assez énorme avec la ligne de commande (30,16" ). Je continuerai demain mes tests préliminaires et ne manquerai pas de venir solliciter de l'aide.
 
Mon intention est de faire un test partiellement complémentaire du tien. Complémentaire parce qu'il portera sur de la musique populaire et non du classique, et parce que je veux tester séparément sur du mono et de la stéréo (j'ai beaucoup de mono, donc je suis curieux des résultats). Partiellement, parce que je vais me limiter aux 3 encodeurs les plus en vue, Flac, MA et Wavpack. J'ai rippé cet après-midi 10 albums stéréo et 10 mono. J'ai hâte de voir ce que ça donne (sans non plus m'attendre à des différences radicales avec ton test sur le classique), mais je veux être sûr d'être parfaitement au point sur la méthode avant de démarrer pour de bon. Et au vu de la grosse bêtise que j'ai déjà faite ce soir, c'était pas un luxe de faire des tests préliminaires.  

J'ai noté une tendance à l'embonpoint chez WavPack avec certains fichiers mono (une différence qui peut atteindre les 80 kbps par rapport à flac, qui déjà n'est pas particulièrement brillant, avec en plus une base de 300...400 kbps environ). J'ai soumis le problème à David, pour qu'il puisse essayer d'en déterminer la cause. Cela ne concerne cependant pas tous les disques (avec d'autres, il arrive à WV4 de faire mieux que Monkey).
 
Je ne serais pas surpris que ton test mette en évidence certains de ces problèmes. En tout cas, j'ai hâte de voir les résultats

Après une matinée passée à rebooter ma machine (22 tests, donc 22 reboots   ), me voilà rassuré sur plusieurs plans mais toujours un peu perplexe sur un autre.
 
J'ai changé de fichier et essayé un peu toutes les configurations possibles, voilà ce que ça donne avec un fichier de 433 Mo encodé en mode normal, sans paramètres :
 
Encodage
Foobar avec buffer, priorité maximale au core et à l'encodage (3 tests) : 25,87" / 26,11" / 26,00"
 
Foobar avec buffer, priorité normale au core et à l'encodage (3 tests) : : 26,12"
 
Foobar avec buffer, priorité normale au core et maximale à l'encodage : 26,07"
 
Foobar avec buffer, priorité maximale au core et normale à l'encodage : 26,03"
 
Foobar sans buffer, priorité maximale au core et à l'encodage (3 tests) : 27,23" / 27,23" / 27,23"
 
Ligne de commande (3 tests) : 20,45" / 20,34" / 20,36"
 
Décodage
 
Speedmeter avec buffer, priorité normale au core et à l'encodage : 23,21"
 
Speedmeter sans buffer, priorité normale au core et à l'encodage : 24,50"    
 
Speedmeter avec buffer, priorité normale au core et maximale à l'encodage : 23,51"
 
Speedmeter sans buffer, priorité normale au core et maximale à l'encodage : 23,37"
 
Speedmeter avec buffer, priorité maximale au core et normale à l'encodage : 24,21"
 
Speedmeter sans buffer, priorité maximale au core et normale à l'encodage : 24,42"
 
Ligne de commande (3 tests) : 20,16" / 19,83" / 19,92"
 
 
Ce que j'en déduis :
 
* Ma configuration au niveau des disques durs dans l'optique de réduire l'incidence de l'activité disque semble à peu près optimale, puisque les différences entre encodage avec et sans buffer sont très minimes. Je pouvais l'espérer en utilisant 2 disques séparés et défragmentés, chacun sur leur nappe propre, mais j'en ai la confirmation.
 
* Les options de priorité, soit du core, soit de l'encodage, n'ont semble-t-il guère d'influence, du moins sur un temps d'encodage très court suivant un reboot. Il pourrait en être autrement sur un encodage beaucoup plus long, cela dit.
 
* L'encodage/décodage en ligne de commande reste systématiquement le plus rapide, et de très loin. A l'encodage, malgré une lecture du fichier source sans tampon, ce qui peut encore se comprendre puisqu'il est apparent que celle-ci influe peu dans ma configuration. Mais surtout au décodage, malgré une mise en tampon de la source ET une écriture en RAM grâce à foo_null. Or là, logiquement, retirer le temps de lecture ET le temps d'écriture devrait donner un avantage au Speedmeter de Foobar. Or il n'en est rien.
 
C'est ce dernier point qui me rend perplexe sur la méthode la plus juste à adopter pour l'ensemble des décodeurs. Si Foobar rajoute un temps indéterminé à l'encodage, comment s'assurer qu'il est le même pour Flac, MA et Wavpack, afin de les laisser à pied d'égalité ? Et en admettant que ce délai supplémentaire (initialisation de l'exécutable ?) soit le même pour tous les profils d'un même encodeur, ce qui est probable, il fausse la comparaison entre un mode très rapide pour lequel il représentera un pourcentage non négligeable du temps d'encodage, et un mode bien plus long auquel il ne rajoutera qu'un faible pourcentage. Ne vaudrait-il donc mieux pas encoder avec la version ligne de commande pour chacun des encodeurs, en sachant que les activités disques ont été dans mon cas réduites au minimum au préalable ?
 
Au secours, je suis perdu !

Tes chiffres me sidèrent, je l'avoue.
Je vais tenter de voir ce qu'il en est de mon côté, en comparant les vitesses obtenues par l'utilisation manuelle de l'exécutable et celle qu'en fait foobar2000.
 
Je crois me souvenir que j'avais réalisé une comparaison similaire à la fin de l'été dernier, et que les perfs de foobar2000 semblaient plus stables et légèrement supérieures - d'où l'adoption. Mais je n'en suis pas certain non plus. Il est possible que j'ai opté pour foobar2000 parce qu'il était à même de calculer à la milli-seconde la durée des opérations effectuées. C'est très important également. Bref, mes souvenirs sont partiellement effacés, et guère utile.
 
Merci d'avoir poussé tes tests - je vais tenter de vérifier de mon côté
 
 
 
P.S. le vieux bug de la console de foobar2000 : x4,2 correspond à x4,02, et pas 4,20 (la même chose s'applique à y,1...9). Cela peut avoir une importance dans certains cas.

Encore deux questions, cette fois avec MA et Flac, toujours dans l'optique de comparer l'encodage avec Foobar et en mode natif.
 
* Si j'encode du MA avec Foobar, j'ai le choix entre :
  - l'exécutable, auquel cas j'ai un timing à la fin qui est faussé par l'écriture d'un fichier temporaire puisqu'il semble qu'il ne soit pas possible de faire sans (je n'ai pas réussi, en tout cas).
  - foo_monkey.dll, qui n'a pas ce problème, mais par contre ne m'affiche pas le temps d'encodage dans la console.
 
* Avec FLAC, c'est le problème inverse. Foobar m'informe bien du temps d'encodage, mais pas la ligne de commande.   J'ai relu 3 fois le fichier d'aide (- --Help) mais n'ai vu aucune option qui permette ça. Ca me paraît gros, quand même, donc je pense que j'ai dû rater quelque chose.
 
Pfiouuuu, c'est laborieux.  
 

L'encodage avec MAC via mac.exe ne nécessite pas la création de fichiers intermédiaires.
 
Je ne saisis pas la nature de tes difficultés avec flac. Tu veux faire quoi au juste ?

ERRATA: je dois faire erreur pour Monkey's Audio. Je regarderais le détail des commandes de mon diskwriter sitôt que j'aurais accès à mon PC perso.

Lire le temps d'encodage. En boîte DOS, Flac me dit quelle taille fait le fichier, mais ne me précise pas combien de temps il a passé à le compresser. Ca paraît tellement basique comme renseignement que je me dis que ça doit être moi...  

Je ne suis pas certain que tous les encodeurs disposent de cette option (affichage de la durée de l'opération). C'est pour cette raison que j'ai opté pour le décodage via foobar2000, puisque tous les encodeurs testés (au décodage au moins) bénéficiaient de conditions identiques, à l'exception d'ALAC.

Y-a-t-il un moyen de mettre l'équalizer dans foobar ? Je veux dire , l'intégré a foobar, sans faire a chaque fois foobar2000/preference/playback/dsp manager/equalizer  ???

non

Je crois qu'effectivement, ça va se révéler être la solution la moins pire.   Ca m'ennuie tout de même parce que le but principal de ce test, très égoïstement, était avant tout de comparer les différents profils Wavpack, les 2 autres encodeurs étant là à titre de référence et d'information pour rendre la chose plus intéressante pour plus de personnes (en clair : quels que soient les résultats, je ne repasserai pas à Flac ou MA). Si le diskwriter rajoute un temps d'encodage fixe à chaque fichier, ça va me fausser l'écart entre les modes rapides et les modes plus lents.
 
D'un autre côté, si Flac n'est pas fichu de me dire combien de temps ça lui a pris pour encoder un fichier, impossible de garder la ligne de commande pour les 3. Dilemme, dilemme...  

pour la ligne de commande flac, tu peux faire un time juste avant et après ta ligne de commande pour connaitre le temps d'encodage

Merci.   Je vais tester avec ça, afin de comparer Foobar et la ligne de commande. je verrai ensuite ce qui me paraît le plus fiable si les différences sont conséquentes.

Suite de mes aventures.  
 
 
J'ai encodé en Wavpack -f mes 20 albums rippés (10 stéréo, 10 mono). J'ai testé successivement avec la ligne de commande, l'interface de Speek et Foobar. Les résultats confirment en majeure partie ce que j'avais constaté plus haut (sous réserve que je ne commette pas une erreur quelque part, ce qui est évidemment possible).
 
 
Source : 20 CD / 14:32:52 / 9 875 061 040 octets
Effacement des fichiers encodés et reboot entre chaque test
Wavpack 4.2 officielle (pas la version optimisée Intel sur Rarewares).
Config Foobar : mise en buffer du fichier complet pour l'encodage/décodage, utilisation de Speed Meter pour le décodage. Priorité normale pour le core comme pour le diskwriter.  
 
1 - Encodage
 
Ligne de commande : 453,19"
Wavpack Frontend  : 468,90" (3,47% plus lent)
Foobar               : 562,75" (24,18% plus lent)
 
2 - Décodage
 
Ligne de commande : 406,40"
Wavpack Frontend  : 424,61" (4,48% plus lent)
Foobar               : 410,15" (0,92% plus lent)
 
On le voit, Foobar est considérablement plus lent que la ligne de commande pour l'encodage. Pour le décodage, malgré la mise en buffer complète de chaque fichier et l'écriture en RAM, il n'arrive qu'à un presque ex-aequo. Par contre, utiliser l'interface de Speek ne fait guère de différence pratique avec la ligne de commande (ce qui est heureux puisqu'il s'agit d'un GUI minimaliste et spécialisé).
 
Pour les résultats individuels de chaque CD, la fourchette est de 21,70% à 29,60% de temps d'encodage supplémentaire en utilisant Foobar en lieu et place de la ligne de commande.
 
Je referai le même test demain avec Flac (et la commande "time" pour la ligne de commande) afin de voir si la différence moyennne d'encodage/décodage sur 20 albums est la même qu'avec Wavpack.
 
Comme je le disais, c'est laborieux.  

BoraBora> je manque vraiment de temps une fois chez moi pour t'aider dans ces investigations. Je tâcherais cependant de confirmer au plus vite ces résultats étonnant. Il n'est pas normal que l'encodage soit 25% plus lent en utilisant foobar2000, qui ne fait qu'utiliser wavpack.exe

Merci à toi, rien ne presse. J'ai de mon côté beaucoup de temps puisque d'une part je suis plus ou moins en vacances, et d'autre part ma carte graphique m'a lâché et sa remplaçante provisoire ne me permet pas de jouer à WoW.    

Je soupçonne le piping opéré par Foobar, à vrai dire. Mais n'étant pas programmeur, et ne comprenant pas grand chose à tout ça, je n'irai pas m'avancer.  
 
Voici d'autres tests que j'ai fait ce matin, uniquement sur l'encodage, dans les mêmes conditions que ci-dessus, si ce n'est les variations sur le buffer :
 
FLAC -0
 
Ligne de commande : 437,81" (mesuré avec la commande "time" dans un batch)
Foobar avec buffer : 535,50" (22,31% plus lent)
Foobar sans buffer : 562,03" (28,37% plus lent)
 
Monkey's Audio (Fast)
 
Ligne de commande             : 733,50"
Foobar + dll sans buffer      : 823,00 " (12,2% plus lent)
Foobar + Mac.exe sans buffer  : 994,68" (35,61% plus lent)
 
Pour la ligne de commande, j'ai simplement relevé les temps affichés. Pour Foobar + la .dll, j'ai été obligé de chronométrer manuellement (pas d'affichage du temps dans la console). Pour Foobar + Mac.exe, c'est le relevé de la console. Au vu du score Foobar + Mac.exe, on voit clairement l'incidence du passage par un fichier temporaire. J'essaierai peut-être cet après-midi avec le GUI MA, juste par curiosité.
 
Ce dernier test semble indiquer qu'un comparatif Foobar + Wavpack.exe vs Foobar + foo_monkey.dll donne un avantage considérable à MA puisque l'allongement du temps d'encodage est de 24,18% pour Wavpack et seulement 12,2% pour MA. L'écart est même encore un poil plus grand puisque j'avais mis le buffer à 0 pour les tests MA.  

Es-tu inscrit sur HA.org ? Poster les résultats permettraient éventuellement d'obtenir une explication (de Peter ou d'un autre), ou du moins des contre-tests d'autres utilisateurs. Si un ralentissement de 25% environ a lieu indépendamment du codec, des optimisations devraient être réalisables. Beaucoup utilisant fb2k pour le transcodage, le gain en perf seraient intéressant.
 
J'ai quand même hâte de tester cela de mon côté.
 
P.S. Si tu as un peu le temps, essaie de voir ce qu'il en est avec d'autres interfaces d'encodage (multi-frontend, dBpowerAmp [le poil à gratter d'HA, qui démangerait bien Peter s'il s'avérait être + rapide ], Frontah, etc...].

Effectivement, j'avais pensé à HA, j'avais juste un peu peur de me lancer. Aller dire au matou irascible qu'il est possible que son soft soit peu optimisé... brrrrrr.  
 
Que penses-tu de cette approche ?

 
Peut-être trop de circonvolutions ? Je gagnerais peut-être à être plus direct ?
 
P.S. : To the english readers who might happen to read this: the above quotation is a nth degree joke and must not be taken seriously. I mean, really.
 
P.P.S. :
- Oh? Is that you, Peter? How you doi...
- ...
- Take off my glasses? Why should I take off my glas...
- ...
- ARRRGH! NOT THE HEAD!
- ...
- UMMMMMFF! MY BALLS!
- ...
- MOMMYYYYYYYYYYYYYYYY!!!!!!!
 
 
 
 
 

Quoté pour donner le link sur Ha
 
Sinon bonne initiative, dont j'avais du mal a percevoir l'intérêt au début, mais qui si elle permet d'améliorer la vitesse d'encodage sous foobar se révèlera des plus utiles. Dépêche-toi quand même parce que la v0.9 ne devrait pas tarder et a été annoncée comme étant la dernière grosse évlution avant un bon bout de temps

MDR  

Bon, mon sort est scellé (pourvu qu'il soit en vacances, pourvu qu'il soit en vacances, pourvu qu'il soit en vacances...).    
 

Bah en fait, l'intérêt pour moi au départ était juste de faire une comparaison équitable de codecs, en repompant sans vergogne tout le travail abattu par gURuBoOleZZ avant moi. Cette histoire de lenteur de Foobar comparé au DOS est arrivée comme un cheveu dans la soupe, ce n'était pas l'objet de mes tests.  

J'ai testé ce matin en encodage seul 3 autres GUIs, et encore une fois cela confirme un vrai problème de lenteur avec Foobar.
 
Déjà fait :
 
* Ligne de commande : 453,19"
* Wavpack Frontend  : 468,90"
* Foobar               : 562,75"
 
Ce matin :
 
* Frontah 0.92 beta 2 : 461"
* Multi-frontend : 453,01"
* Monkey's Audio GUI : 454,34"
 
Pour Frontah, j'ai relevé les temps affichés en fin d'encodage dans le GUI, exprimés en secondes (rien après la virgule).
Pour Multi-frontend, ce sont les temps affichés par la boîte DOS.
Pour Monkey's, ce sont les temps affichés par le GUI.
 
Pour dBpowerAmp, est-il possible de passer par l'exécutable ? Car le codec téléchargeable sur le site est basé sur Wavpack 4.1 et j'aime autant ne pas installer inutilement un soft sur ma machine.  
 
Pour l'instant, la pêche est pauvre sur HA. On m'a demandé si Replaygain et/ou des DSP n'étaient pas activés. Question pertinente, mais puisque ce n'est pas le cas je suis pas plus avancé.
 
Dans tous les cas, je suis maintenant à peu près convaincu de la nécessité de faire mon test comparatif de codecs en utilisant la ligne de commande pour les codecs basés sur un exécutable DOS. Je n'ai plus aucune confiance dans les GUIs. Je vais sans doute commencer aujourd'hui, et reviendrai sans doute poser quelques questions avant de tirer ma révérence.    
 
P.S. @ Guru : sur un tout autre sujet, tu as vu qu'un posteur français d'HA a entamé une traduction dans un anglais assez approximatif de ton guide Foobar ?

je n'ai pas tout suivi mais bon : en plus du Replaygain et/ou des DSP, tu a verifie aussi que le dithering etait desactive, et que la priorite etait la meme que celle utilise par les autres font-end ?

Dithering désactivé, oui. Priorité, j'ai essayé un peu tout, voir plus haut.
 
En fait, le plus simple serait que quelqu'un fasse le même test, même avec juste un CD.    

Bon pas trop le temps de faire un truc clean, mais a la volee j'ai essaye d'encoder 3 wav en lame 3.96 -pfm avec foobar puis razorlame. Sans prendre de precautions genre reboot etc... :
Foobar me donne

 
et razorlame :

j'ai donc une difference de 6 a 10% seulement.
Si j'ai le temps j'essayerai ce week-end plus rigoureusement. Mais cet ordre de grandeur n'est pas choquant.

C'est peut etre pas choquant mais ca confirme quand même dire que foobar est réellement plus lent
Dire que j'encode uniquement avec foobar ces derniers temps (A part les rips via eac)

Je comprends pas vos histoires.
Si l'encodeur est le même et qu'il est appelé dans les mêmes conditions, peut pas y avoir autant de différence!
Avez-vous la moindre idée de la mnière qu'a foobar de mesurer le temps?

Nous non plus.    

Justement, c'est là que le bât blesse : est-il appelé dans les mêmes conditions ? Peut-être Foobar fait-il un appel à l'exe tous les x cycles qui n'est pas nécessaire quand on encode sous DOS ? Je n'en sais trop rien, la programmation c'est du chinois pour moi.  

Je pense pas que ce soit le timing renvoyé par Foobar qui soit en cause, puisque j'ai chronométré manuellement l'un des encodages que j'ai fait (cf plus haut pour MA).
 
 
Sinon, j'ai fait aussi le test avec LAME, mais sur 2 CD seulement :
 
Ligne de commande : 607"
Foobar : 626"
 
Donc différence insignifiante. On pourrait essayer plusieurs autres codecs lossy pour voir, mais j'avoue que ça me saoûle un peu, vu que je n'étais pas parti au départ pour un comparatif de vitesse d'encodage entre interfaces graphiques.  

 
Il faut savoir que des fois les plus grandes découvertes sont les fruits du hasard...
   
 
En tout cas, c'est très intéressant et je suis ça depuis le début avec attention !

J'spère d'ailleurs recevoir l'année prochaine le prix Nobel de...... hum.... nerditude ?  
 

 
Effectivement, surprise dès mon 2ème test. Je n'ai fait que Wavpack fast et normal, mais que vois-je sur les sous-totaux des 10 albums mono ?
 
Ratio (en %) Fast/Normal :
 
32,95/33,02
42,01/42,76
57,73/56,53
33,24/33
45,31/40,55
39,05/38,02
42,46/39,79
42,97/42,44
46,79/46
40,58/40,07
 
Gasp ! Sur les deux premiers CD, Wavpack compresse un chouia plus en fast qu'en normal.
 
Sinon, les nouvelles du front : sur HA, Picmixer a suggéré que cette différence de temps d'encodage puisse être causée par le traitement interne du son en 64bits de Foobar. Néanmoins, ça n'explique pas la différence entre un encodage en Wavpack (différence énorme avec la ligne de commande) et LAME (différence insignifiante). Et puis je ne vois franchement pas en quoi le son serait "traité" lors d'un encodage sans DSP avec le CLI de Foobar ?
 
Par contre, toujours personne qui veuille faire le même test que moi, même là-bas, afin qu'on sache au moins si ça vaut la peine de continuer à se creuser la tête ou si c'est juste moi qui m'y suis pris comme un pied.  

Tu vas trouver que j'exagère, mais je n'ai pas réussi à trouver le temps de faire un test qui pourtant devrait m'occuper pendant 10 minutes à peine. J'en ai honte. Pour ma décharge, je dois signaler que j'ai du me battre avec un graveur de DVD qui refuse de dépasser les x2, une carte mère capricieuse doublé d'un OS qui refusent de fonctionner selon des combinaisons IDE/maître esclave qui dépassent toute rationalité, puis cette nuit un disque dur qui claque (j'avais acheté le graveur en parti pour en faire un backup - après une nuit entière à son chevet, j'ai pu récupérer l'essentiel des données, perdant tout juste un fichier mpc pour 6000 récupérés ; je peux dire que j'ai eu chaud !).

hypothèse au pif : foobar lance une nouvelle fenêtre DOS pour encoder chaque morceau, ce que  tu ne fais pas à la main, d'où l'écart.

Toutes mes condoléances Guru...
C'est quoi ton graveur DVD? Y a de bon topics en section hardware (j'ai un Nec 3520 depuis quelques jours).
Sinon t'as encore du MPC? Je te croyais passé du coté Lossless depuis un moment?

LG 4163B. J'avais qq a priori sur la marque, mais la critique de cdrinfo.com m'a convaincu.
 
Oui, j'ai du MPC en réserve, que je n'écoute plus vraiment. Ils étaient stockés sur un disque dur que j'avais débranché. Une grosse moitié venait de rips que je projette de refaire en lossless (j'avais d'ailleurs effacé dans les 5000 fichiers assez récemment, faute de place !). La seconde partie m'est par contre nettement plus précieuse, et c'est elle qu'il me fallait impérativement sauvegarder. J'ai donc fini par me convaincre de l'achat d'un graveur, pensant du coup assurer la collection contre les risques de crash et récupérer les 80 GB de mon ancien disque à des fins plus utiles (le lossless bouffe assez vite tout l'espace). Avoir un disque dur qui flanche quelques jours après avoir eu un graveur : ça c'est du timing  
 
 
P.S. Au fait, merci d'avoir indiqué SuperCOpier dans la liste des logiciels utilese, puisque c'est grace à ce soft que j'ai aisément pu contrôler la copie des données situé sur le disque vacillant vers une unité plus saine. Sans la gestion d'une liste enregistrable, cela aurait été nettement plus galère.

Je vois... un ami m'avait dit du mal du LG et le plus grand bien du Nec mais après que j'eu acheté le dit peripherique un peu sur un coup de tete à Moncailloux à vrai dire...
Ceci dit je n'ai pas encore éprouvé la bete je viens tt juste de recevoir mes DVD+R 16x verbatim..

(oui c'ets pour sauvegarder le contenu de mon iHP, pasque je vivais qd meme dangeresement sans sauvegarde faute de place)
 
Bon courage en tt cas...
++

C'est tout ce que vous avez comme justification ? Il vous faudra trouver mieux, mon cher !  
 
Bon, sérieusement, tous mes souhaits accompagnent ton micro pour un prompt rétablissement. C'est d'ailleurs fou à quel point les problèmes de bécane arrivent si souvent en cascade, donnant parfois envie de jeter tout le bazar par la fenêtre et revenir au papier et au stylo.
 
Et puis hors la curiosité qui me taraude, je te le répète : rien ne presse.   Ca ne m'a pas empêché de commencer mes tests, puisque tous les codecs que je vais inclure sont des exécutables DOS (j'ai déjà fini 5 codecs/presets, dont MA insane. A cette vitesse, dans 10 jours c'est bâclé).
 

 
Mmmmmh... pas bête, à vérifier.   Je re-ripperai un de mes 20 CD demain sans créer d'image et comparerai.

 
Je mets moins de temps pour boucler un test qui s'annonce bâclé  

Salut, j'avais vu je crois sur ce topic un plug-in pour qu'on voie la musique qu'on écoute sur msn messenger, mais j'ai la flemme de chercher, il est long ce topik    
 
Quelqu'un pourrait me dire ou le trouver?
 
merci d'avance