Le Topic de la Squeezebox Touch de Logitech

[pem]

@sebp : pourtant paime affirme le contraire un peu plus haut...

pem n'a jamais dit qu'il utilisait les sorties analogiques de la Touch pour écouter ses FLAC/DTS.
(remarque, il n'a jamais dit non plus que c'était du DTS )

non ce n'était pas du DTS et j'utilisais que les sorties analogiques (donc je ne profitais que de 2 canaux).
Le but était de tester pour voir si différence audible, car sinon taille du fichier trop important : 400 Mo la chanson.......

Sinon, le DTS doit pouvoir être converti en PCM, non ?

[sebp]

non ce n'était pas du DTS et j'utilisais que les sorties analogiques (donc je ne profitais que de 2 canaux).

C'est vrai que le format FLAC supporte le multicanal nativement, je n'y pensais plus.

Sinon, le DTS doit pouvoir être converti en PCM, non ?

Certainement, mais l'intérêt me semble plus que limité si tu ne profites que de deux canaux d'un mixage prévu pour 5 ou plus.

[dafunky]

oui je vais envisager de faire ça, je verrai bien combien ça pèse du 5.1 initialement compressé DTS puis décompressé puis recompressé lossless FLAC.
En fait même si ma SBT (dans ma SDB) ne lit que les deux canaux principaux, je préfère garder ce mode dégradé et ainsi dans mon salon je peux utiliser SqueezeSlave pour le 5.1 (ça m'ennuie d'avoir à utiliser un autre logiciel, et je commence à prendre goût à squeeze commander et à la synchro des platines

[Jonathan]

Dommage, cette analyse ne donne aucun chiffre sur les temps de décompression.

Bonjour,
Je suis l'auteur de la page citée depuis quelques messages. Je prends note de votre remarque. Lors de la prochaine mise à jour du site (dans quelques mois), je tenterai de mettre sur pied une méthode pour mesurer le temps de décompression. Si les résultats sont intéressants, ils seront publiés.
J'en profite pour rappeler que les chiffres diffusés sur mon site sont à peine représentatifs sur un ordinateur. Amha, on ne peut pas extrapoler ces résultats sur une autre plate-forme. L'architecture des SB (parfois très proche d'un modèle à l'autre) n'a rien de comparable à celle d'un PC.

Longue vie au FLAC !

[sebp]

Voici les résultats d'un petit test que je viens de m'amuser à réaliser sur mon Mac :

• -5 : 4,893 s
• -6 : 4,972 s
• -7 : 4,831 s
• -8 : 5,343 s

Les temps donnés sont pour la moyenne des trois derniers temps passés par la commande flac -t <fichier> sur le processeur (%user) d'une série de 4 commandes (la première exécution, non prise en compte, servant à charger le fichier testé dans le cache disque du système).
Les fichiers FLAC ont été générés avec la v1.2.1 des utilitaires ligne de commande, à partir d'un même fichier WAV 24/96 pour que le temps de décompression soit suffisamment significatif.

On peut voir que la commande FLAC a passé 9% de temps en plus sur le processeur pour décompresser le fichier encodé en niveau 8 que celui encodé en niveau 5 (standard).
Mais curieusement, on s'aperçoit que le niveau de compression 7 requiert moins de temps processeur pour être décodé que le niveau 5 (j'ai vérifié plusieurs fois que je ne m'étais pas gouré en générant le fichier, et ai également pu le vérifier sur un simple fichier 16/44,1).

Comme je ne sais pas quelle version du décodeur FLAC est embarqué dans les Squeezebox, difficile de dire quel niveau de compression sera le plus adapté.
L'idée de ce test était simplement de montrer que le niveau de compression a un impact, certes réduit, mais réel sur les ressources nécessaires au décodage.

[silvermica]

Salut sepb je vois que tu est spécialiste du Flac ,j'ai ripper tout mes cd en Flac ( un gros boulot) pour ce faire j'utilise Vu Player dans ce logiciel le niveau de compression
est paramétrable je l'ai regler a 0 sur une echelle de 5. Cela marche tres bien cela supporte la comparaison avec le PMDT ,mais bon le gain en volume occuper est quasi nul
A quel niveau de compression peut on aller sans perte de qualité?
Je rippe sur un pc et la lecture se fait sur une dune HD base 3.0

[pem]

Bonjour,
Je suis l'auteur de la page citée depuis quelques messages. Je prends note de votre remarque.
(......)
Longue vie au FLAC !

Salut, bravo pour le site (participation/globalité ?), il est très intéressant.

Voici les résultats d'un petit test que je viens de m'amuser à réaliser sur mon Mac :

• -5 : 4,893 s
• -6 : 4,972 s
• -7 : 4,831 s
• -8 : 5,343 s

Intéressant...c'est vrai que le résultat du -7 est bizarre

[sebp]

A quel niveau de compression peut on aller sans perte de qualité?

Si ça correspond aux niveaux de compression de FLAC (qui vont de 0 à 8 ), ça n'a aucune incidence sur la qualité du fichier généré, seulement sur sa taille, et sur le temps nécessaire pour l'encodage.
Jonathan explique ça très bien dans sa page consacrée au sujet.
Je me suis contenté d'illustrer le fait que les ressources CPU nécessaires pour le décodage variaient légèrement selon le niveau de compression choisi.

[phabaudio]

Dommage, cette analyse ne donne aucun chiffre sur les temps de décompression.

Bonjour,
Je suis l'auteur de la page citée depuis quelques messages. Je prends note de votre remarque. Lors de la prochaine mise à jour du site (dans quelques mois), je tenterai de mettre sur pied une méthode pour mesurer le temps de décompression. Si les résultats sont intéressants, ils seront publiés.
J'en profite pour rappeler que les chiffres diffusés sur mon site sont à peine représentatifs sur un ordinateur. Amha, on ne peut pas extrapoler ces résultats sur une autre plate-forme. L'architecture des SB (parfois très proche d'un modèle à l'autre) n'a rien de comparable à celle d'un PC.

Longue vie au FLAC !

Merci pour avoir pris le temps de réaliser cette page instructive.
Pour ce qui est de la plateforme d'exécution utilisée, mon avis est que ça n'a pas d'importance, pour autant que les mesures soient toutes effectuées sur la même machine et que le temps de codage/décodage moyen soit significatif (c'est à dire suffisamment grand) par rapport au temps requis pour le lancement de la commande utilisée.

[phabaudio]

A quel niveau de compression peut on aller sans perte de qualité?

Si ça correspond aux niveaux de compression de FLAC (qui vont de 0 à 8 ), ça n'a aucune incidence sur la qualité du fichier généré, seulement sur sa taille, et sur le temps nécessaire pour l'encodage.
Jonathan explique ça très bien dans sa page consacrée au sujet.
Je me suis contenté d'illustrer le fait que les ressources CPU nécessaires pour le décodage variaient légèrement selon le niveau de compression choisi.

La différence de 10% entre les extrêmes des temps de décodage que tu as relevés en fonction du niveau de compression est finalement plutôt négligeable. Du coup je ne vois pas vraiment l'intérêt d'utiliser un bas niveau de compression, compte tenu que pour un format audio le temps de décodage me semble tout de même plus critique que celui requis pour le codage (?)...

[Pilru]

Extrait de la FAQ de http://flac.sourceforge.net/

Why do the encoder settings have a big effect on the encoding time but not the decoding time?

It's hard to explain without going into the codec design, but to oversimplify, the encoder is looking for functions that approximate the signal. Higher settings make the encoder search more to find better approximations. The functions are themselves encoded in the FLAC file. Decoding only requires computing the one chosen function, and the complexity of the function is very stable. This is by design, to make decoding easier, and is one of the things that makes FLAC easy to implement in hardware.

Le niveau de compression joue principalement sur le temps mis a encoder.

[phabaudio]

Extrait de la FAQ de http://flac.sourceforge.net/

Why do the encoder settings have a big effect on the encoding time but not the decoding time?

It's hard to explain without going into the codec design, but to oversimplify, the encoder is looking for functions that approximate the signal. Higher settings make the encoder search more to find better approximations. The functions are themselves encoded in the FLAC file. Decoding only requires computing the one chosen function, and the complexity of the function is very stable. This is by design, to make decoding easier, and is one of the things that makes FLAC easy to implement in hardware.

Le niveau de compression joue principalement sur le temps mis a encoder.

Merci pour cette référence. Conclusion : à l'avenir je flaque avec le curseur à donf !

[Gandalflux]

Comme tu le sent

[sebp]

La différence de 10% entre les extrêmes des temps de décodage que tu as relevés en fonction du niveau de compression est finalement plutôt négligeable.

Tout est relatif ...

[Jonathan]

Voici les résultats d'un petit test que je viens de m'amuser à réaliser sur mon Mac :

• -5 : 4,893 s
• -6 : 4,972 s
• -7 : 4,831 s
• -8 : 5,343 s

On peut voir que la commande FLAC a passé 9% de temps en plus sur le processeur pour décompresser le fichier encodé en niveau 8 que celui encodé en niveau 5 (standard).
Mais curieusement, on s'aperçoit que le niveau de compression 7 requiert moins de temps processeur pour être décodé que le niveau 5

Probablement une bizarrerie de l’algorithme ou alors la volonté du développeur. Autre hypothèse. Ce comportement me rappelle celui du Zip. Dans certains cas la compression maximale ne réduit pas la taille des archives, elle l’augmente même. Le temps de compression est très long pour un bénéfice nul ou négatif. Bref, le mieux est l'ennemi du bien.

Même si FLAC est « asymétrique » (il va beaucoup plus vite en lecture), la grande complexité des fichiers -8 finit par avoir un impact négatif en lecture.

Bonjour,
Je suis l'auteur de la page citée depuis quelques messages. Je prends note de votre remarque.
(......)
Longue vie au FLAC !

Salut, bravo pour le site (participation/globalité ?), il est très intéressant.

Globalité, merci pour vos encouragements

Merci pour avoir pris le temps de réaliser cette page instructive.

C'est peu de chose. Vous en faites tous autant (et même plus) ici.

Pour ce qui est de la plateforme d'exécution utilisée, mon avis est que ça n'a pas d'importance, pour autant que les mesures soient toutes effectuées sur la même machine et que le temps de codage/décodage moyen soit significatif (c'est à dire suffisamment grand) par rapport au temps requis pour le lancement de la commande utilisée.

Nous sommes d'accord sur essentiel. L'échantillon doit être suffisamment important (et identique d'un test à l'autre) pour constater une différence (en compression et décompression). Maintenant d'un point de vue performances pures, au mieux mes chiffres donnent une tendance sur PC. Il ne faut pas sous-estimer l'impact du matériel, mais surtout celui du logiciel. Il existe des versions modifiées de l'algo FLAC officiel. Au menu, optimisations des performances en tenant compte des spécificités des CPU. Il suffit de fouiller un peu dans hydrogenaudio.org pour en savoir plus.

Pour fini, j'ajouterai que FLAC est un merveilleux outil (comme les SB !). Si ses performances (avec la version actuelle) ne sont pas au top, il a de nombreux atouts qui compensent largement (amha).