Modérateurs: Modération Forum Home-Cinéma, Le Bureau de l’Association HCFR • Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 37 invités

Tout ce qui concerne les logiciels lié au HC sur ordinateur (PC, Mac, Linux...)
Règles du forum
Avant de poster, merci de prendre connaissance des règles du forum : à lire avant de poster

XXHighEnd, CMP, Winamp, etc : des concurrents pour Foobar ?

Message » 04 Nov 2008 19:01

Fyber a écrit:Pensez-vous qu'il y ait un quelconque intérêt à installer une CS de qualité si on sort en numérique vers un DAC?


Ben justement je pensait que non , ben depuis que je suis passé de mon chipset integré de mon vieux portable (STAC je sais plus quoi) au chipset integré de ma carte mère (ALC883) j'ai noté une nette amélioration générale .
AlexScan
 
Messages: 10614
Inscription Forum: 27 Déc 2005 20:57
Localisation: Val d'Oise
  • offline

Message » 04 Nov 2008 19:19

En ce qui me concerne, étant sous XP et sortant en analogique, je ne peux guère répondre à tes questions. Hormis peut être le choix des players. S'ils sortent en KS ou ASIO, (ou autre protocole bit perfect sous Vista) c'est probablement tout bon. Maintenant, il faudrait vérifier tout ça... Mais avec un chipset audio sur CM, ça va pas être simple :-?

>Pensez-vous qu'il y ait un quelconque intérêt à installer une CS de qualité si on sort en numérique vers un DAC?

tu aura probablement moins de jitter sur ta sortie SPDIF avec une CS pro.

Après, en terme d'audibilité en écoute stéréo (flux PCM transmis via le protocole SPDIF), co le dit seb.26, tout dépend de la sensibilité au jitter des circuits d'entrés de ton DAC...

En ce qui concerne le buffer, il y a qd même un soucis car vu qu'il y a forcément un delta de fréq. inévitable entre l'horloge du DAC (qui consomme les données du buffer) et l'horloge véhiculée par la SPDIF qui alimente le buffer, à un moment donné, ça coince forcément. Par exemple, si les données arrivent un chouille + vite que le DAC les consomme, le buffer va se remplir inexorablement jusqu'à "déborder". Et là on ne peut pas faire autrement que virer des samples sans que le DAC ne les consomme.

Dans l'autre sens, si les données arrivent un chouille - vite que le DAC les consomme, à un moment donné le buffer va être vide et il y aura un "blanc".

Maintenant peut être que cela arrive suffisamment rarement pour être négligeable si le buffer est correctement dimensionné, il faudra faire un petit calcul pour voir ...

Avec le système par interruption décrit plus haut, cela n'arrive jamais car le fichier audio est lu au fur et à mesure des "besoins de consommation" du DAC de la CS (enfin normalement si c'est bien fait) : c'est de la lecture asynchrone de fichier.
Emmanuel Piat
Contributeur HCFR 2016
 
Messages: 10347
Inscription Forum: 10 Oct 2000 2:00
Localisation: Besançon, FRANCE
  • offline

Message » 04 Nov 2008 20:55

Emmanuel Piat a écrit:Le player lit le fichier audio (wav, flac, etc.), le décode avec une réso cible (16, 24 ou 32 bit), lui fait subir éventuellement des filtrages (eq, SRC, etc.), du dithering, etc ...

Tous ces traitements sont effectués en RAM sur des buffers (qq ms à qq sec.)

Ensuite le player doit dialoguer avec le driver de la CS en lui disant ou est le buffer à lire (ie celui qui contient les données PCM c-à-d. les amplitudes des samples qui ont été traités par le player). Plusieurs protocoles sont possibles : directsound, KS, ASIO, etc. Certains sont bit-error free (KS et ASIO), d'autres modifient les amplitudes fournies par le player (directsound sous XP par exemple).

Le driver lui envoie les données à la CS "qd c'est nécessaire" (voir + bas). Le principe est toujours le même depuis que les cartes son existent (atari, amiga, etc.) :

Qd le buffer du DAC est presque vide, la CS envoie un signal d'interruption au PC. Celui-ci choppe ce signal, lui donne une priorité (car il faut y avoir d'autres sources d'interruption) puis la traite "dès qu'il a le temps". le driver envoit alors les PCM bufferisées dans la RAM du PC dans le buffer que la CS jusqu'à ce qu'il soit plein.

Donc pour résumer : d'un côté tu as un buffer ds la RAM du PC qui est remplit par le player et de l'autre côté tu as un buffer ds la CS qui est vidé par le DAC. Le buffer du PC se vide dans le buffer de la CS à chaque interruption demandée par la CS (ie lorsque le buffer de la CS est presque vide).


Merci Emmanuel pour ces explications, je comprends à présent le chemin emprunté par un fichier audio quand il est lu sous windows.

En savons nous plus sur ce travail effectué dans le player :
lit le fichier audio (wav, flac, etc.), le décode avec une réso cible (16, 24 ou 32 bit)

Est ce qu'il s'agit d'une opération effectuée dans une norme MS ou bien chaque éditeur est le propre dév. de ces programmes?

Question newbie, la gestion des buffers qui est effectuée par les drivers ASIO. Peuvent-ils être source de jiiter ou bien cette notion n'existe pas à ce stade là de la lecture?

Thanks,
Mathieu
yy
 
Messages: 2008
Inscription Forum: 27 Juil 2003 15:27
  • offline

Message » 05 Nov 2008 7:19

Est ce qu'il s'agit d'une opération effectuée dans une norme MS ou bien chaque éditeur est le propre dév. de ces programmes?


pour la lecture du fichier il y a une API windows, ensuite pour le decodage c'est soit fait par des filtres directshow, soit en interne par le player. Mais dans le cas de formats lossless (ape, flac) ca a peut d'importance puisque les algorithmes sont deterministes.
A l'interieur du PC il n'y a pas de jitter, les donnees ne sont pas envoyees en flux tendue mais avec un systeme de buffers/irq comme l'expliquait emmanuel.
vairulez
 
Messages: 3588
Inscription Forum: 03 Fév 2002 2:00
Localisation: Bordeaux
  • offline

Message » 05 Nov 2008 19:06

Bonjour,

Il me semble qu'une des origine des discussions sur la différence entre players vient d'une mécomprehension sur la nature du codage et du décodage des fichiers. Il faut bien comprendre qu'il s'agit de deux processus qui sont assymetriques.
Quand on code un fichier, quel que soit le codec utilisé (Wav vers flac, mp3, ogg) il y a effectivement des choix de programation quant au résultat final. Le taux de compression par rapport à une qualité sonore comparable dépend du choix des algorithmes et de leur implémentation, c'est-à-dire de l'habilté du programmeur.
Par contre, quand on décode un fichier, il n'y a pas a proprement parlé, par rapport au résultat final, de choix de programation : le processus est conceptuellement équvalent à une décompression de fichier informatique tel les .zip ou les .rar. C'est pour cela qu'une API MS est amplement suffisante.
Certes, Il peut y avoir habileté de la part du programeur. Mais, dans tous les cas, elle n'impacte pas le resultat final mais seulement la manière dont on l'obtient : plus ou moins vite, avec plus ou moins de ressource comsommée, etc.

Voilà, ma petite pierre à l'édifice.

A+
kobtar_bale
 
Messages: 327
Inscription Forum: 09 Fév 2006 17:29
  • offline

Message » 06 Nov 2008 10:05

kobtar_bale a écrit:Quand on code un fichier, quel que soit le codec utilisé (Wav vers flac, mp3, ogg) il y a effectivement des choix de programation quant au résultat final. Le taux de compression par rapport à une qualité sonore comparable dépend du choix des algorithmes et de leur implémentation, c'est-à-dire de l'habilté du programmeur.


oui et non...

wav : pas de compression => c'est juste une mise en forme des échantillons fournis par le DAC (PCM) dans un format informatique : par exemple, ds un logiciel de mastering audio, on va transcoder tous les wav en 32 bit flottants pour avoir une résolution en amplitude quasi "infinie" et éviter les problèmes d'arrondis lors des calculs lorsqu'on modifie les formes d'ondes d'origine (compresseurs, dithering, resampling, etc.). Ensuite à la fin de tous les traitements (et seulement à la fin), on choisit un format cible (wav 16 bits par exemple si on veux faire du CD, 24 bits si DVD etc.) et là encore il y a une nouvelle mise en forme, mais pas de réelle compression de l'info (on perd jusque en précision sur le codage de l'amplitude).

compression/décompression lossless (flac, monkey audio, MLP etc.) : les algo sont déterministes et parfaitement documentés si ds le domaine public. Des API sont parfois fournis. Sinon, le programmeur doit implanter lui-même ces algo ds un langage cible (C, C++, ...). Normalement, si les choses sont faites correctement, il y a des procédures de tests consistant à comparer après encodage puis décodage si on obtient bien ce qu'on est sensé obtenir (c-à-d. 0 différence avec le wav d'origine).

compression/décompression lossy : idem les algos sont parfaitement déterministes et normalisés. Par exemple Dolby et DTS fournissent des procédures pour certifier les algo d'encodage / décodage via des tests (que ces algo tournent sur un PC, un DSP, ou une logique cablée dans une puce). Cette certification a généralement un coût et si on veut s'en passer on peut :wink: Mais alors, on est pas certifié officiellement... Ca a été un des problèmes avec le MP3 où bcp ont fait n'importe quoi sans suivre les normes officielles...

@+
Emmanuel
Emmanuel Piat
Contributeur HCFR 2016
 
Messages: 10347
Inscription Forum: 10 Oct 2000 2:00
Localisation: Besançon, FRANCE
  • offline

Message » 06 Nov 2008 12:26

Emmanuel Piat a écrit:compression/décompression lossy : idem les algos sont parfaitement déterministes et normalisés. Par exemple Dolby et DTS fournissent des procédures pour certifier les algo d'encodage / décodage via des tests (que ces algo tournent sur un PC, un DSP, ou une logique cablée dans une puce). Cette certification a généralement un coût et si on veut s'en passer on peut :wink: Mais alors, on est pas certifié officiellement... Ca a été un des problèmes avec le MP3 où bcp ont fait n'importe quoi sans suivre les normes officielles...


Et pour les decodeurs non officiels obtenu par reverse engineering?
Je pense à ffmpeg.

Je ne dis pas qu'ils font n'importe quoi loin de là, je n'utilise que cette librairie :wink: .

Mais est-ce qu'il est possible que les players l'utilisant pour décoder (ceux qui utilisent ffdshow aussi forcément) puissent alors avoir un moins bon décodage, un moins bon rendu, que le décodeur officiel?
Slacky
 
Messages: 263
Inscription Forum: 26 Déc 2007 19:32
  • offline

Message » 06 Nov 2008 13:03

C'est de la vidéo ou de l'audio ?

Si c'est de la vidéo, à part comparer avec un déco en lequel tu as pleine confiance, je vois pas trop... C'est comme cela que j'avais certifié Dscaler en comparant les frames obtenues avec Nvidia...

Pour l'audio, idem. Par exemple du décode un MP3 avec 2 déco MP3 différents en stockant le résultat en wav (via rewire, loopback and co). Ensuite tu compares sample à sample en ayant recalé temporellement les deux fichiers. Tu peux aussi utiliser le plugin bit compare de foobar...

C'est du boulot mais il m'est arrivé de le faire (notamment pour valider la lecture CD sur mon graveur DVD par exemple).

@+
Emmanuel
Emmanuel Piat
Contributeur HCFR 2016
 
Messages: 10347
Inscription Forum: 10 Oct 2000 2:00
Localisation: Besançon, FRANCE
  • offline

Message » 06 Nov 2008 13:37

Ok merci :wink: ,
C'était pour l'audio dts, ac3, je vais faire des tests.
Slacky
 
Messages: 263
Inscription Forum: 26 Déc 2007 19:32
  • offline

Message » 06 Nov 2008 14:39

Emmanuel Piat a écrit:oui et non...


Vrai, autant pour moi : j'ai manqué de précision entre "coder des donnée", "coder un programme", et "compression".
Cependant il me semble que :
Emmanuel Piat a écrit:compression/décompression lossy : idem [que les lossless] les algos sont parfaitement déterministes et normalisés.

Manque de précision à son tour.

La différence entre le lossy et le lossless est que les algos concernent deux domaines différents : la simplification psycho-acoustique d'une part et la compression proprement dite de l'autre.

Les deux types de codecs utilisent la compression, mais seul les lossy font précéder cette phase d'une simplification psycho-acoustique.

Les algos déterministes des normes dont tu parle concernent, au sens strict, la compression et pas (enfin moins) les phase de simplification. C'est pour cela qu'on peut parler de différences audibles (à bitrate constant) entre différents encodeurs d'une même norme lossy. Pour le MP3, une différence à xxx kb/s entre Itune et Lame par exemple. C'est que, si la phase de compression est toujours identique quel que soit les programmes d'encodage de la norme, la phase de simplification laisse une marge de manoeuvre au programeur. C'est le cas par exemple du parfum Aoyumi (AoTuV) pour l'ogg vorbis.

Ces deux domaine (simplification + compression) unis en général dans un même programme sont distingués dans un codec comme LossyWAV. LossyWAV simplifie un fiche .wav selon des algos (déterministes quoique forcément cumulatifs dès qu'on dépasse une simple quantification dynamique – la recompression donnant un résultat différent de la compression) liée à la psycho-acoustique. Il produit une fichier de taille identique à l'original qu'on pourra compresser par des codecs lossless (Flac Wavpack, Monkey Audio). La différence entre un fichier Wav et Lossy Wav est que le second est plus simple, c'est-dire composé de plus données redondantes (00000001 -> LossyWAV -> 00000000 par exemple), éliminées par la compression mais restituées telles qu'elles (00000000) à la lecture.

Ces deux types d'algos fondent une différence entre les deux types codecs à l'encodage. Mais ce n'est pas le cas au décodage où, effectivement, ils suivent les algos normalisés par la norme du codec ou, mieux dit dans le cas des codecs lossy, la face compressive de la norme, semblable au .zip et au rar mais adaptés au particulatité du format musical (coder la différence entre les canaux gauches / droit plutôt que les canaux eux même par exemple).

Cette précision apportée, le post précédent visait simplement à avancer l'idée c'est sûrement une généralisation mal maitrisée des différences de qualité produite par les programes d'une même norme lossy (Lame est mieux que ITune pour le MP3) qui conduit à l'idée que la qualité sonore dépend de l'habilté du programeur, celui de tel programme faisant mieux que celui de tel autre. On le vois, d'après ce que je viens d'écrire, il s'agit d'une erreur quand cela s'applique au décodage.
Dernière édition par kobtar_bale le 06 Nov 2008 14:51, édité 1 fois.
kobtar_bale
 
Messages: 327
Inscription Forum: 09 Fév 2006 17:29
  • offline

Message » 06 Nov 2008 14:39

Emmanuel , dit moi tu ingénieur son ou quoi ???
AlexScan
 
Messages: 10614
Inscription Forum: 27 Déc 2005 20:57
Localisation: Val d'Oise
  • offline

Message » 06 Nov 2008 19:56

ça fait plaisir de lire ces pages. Instructif et clair.

Merci

Alain :wink:
haskil
 
Messages: 60007
Inscription Forum: 06 Déc 2001 2:00
Localisation: Haute Normandie et Brésil
  • offline

Message » 07 Nov 2008 8:55

AlexScan a écrit:Emmanuel , dit moi tu ingénieur son ou quoi ???


non :wink:
Emmanuel Piat
Contributeur HCFR 2016
 
Messages: 10347
Inscription Forum: 10 Oct 2000 2:00
Localisation: Besançon, FRANCE
  • offline

Message » 07 Nov 2008 9:04

kobtar_bale a écrit:C'est pour cela qu'on peut parler de différences audibles (à bitrate constant) entre différents encodeurs d'une même norme lossy.


j'ignorais ce point et pardonne moi, je suis encore "sceptique".

Normalement, tout compresseur lossy permet d'ajuster un certain nombre de paramètres parfaitement spécifiés et documentés qui vont influer sur les informations supprimée car supposées non perçues. Je pensais que normalement tous les paramètres ajustables du codec étaient forcément accessibles à l'utilisateur (peut être ds un mode expert pour ne pas noyer le néofite, d'autres modes + simples fixant automatiquement certaines valeurs). Ce qui n'est pas ajustable doit avoir des valeurs (uniques) parfaitement définies à l'avance. Sinon, c'est la porte ouverte à n 'importe quoi.

Donc pour moi, si deux encodeur lossy MP3 spécifient exactement les mêmes paramètres d'encodage, il doivent produire le même résultat (et fort heureusement car sinon cela signifie que l'un des deux est erroné). Donc a priori, il semblerait que le flou soit plutôt que certains prog. d'encodage ne donnent pas accès à tous les paramètres pertinents et en fixe d'autoristé certains (avec des choix + ou - heureux) ...
Emmanuel Piat
Contributeur HCFR 2016
 
Messages: 10347
Inscription Forum: 10 Oct 2000 2:00
Localisation: Besançon, FRANCE
  • offline

Message » 07 Nov 2008 11:29

Il y a bien des encodeurs qui proposent différentes qualités d'encodage pour un même bitrate. Que font-ils de plus lorsque l'option "très bonne qualité" est cochée par rapport à "basse qualité"?

Mais de quelle qualité est-il question ? qualité sonore ou qualité de compression (c'est à dire moins de place de stockage occupé pour le même résultat) ?
rycil
 
Messages: 1044
Inscription Forum: 22 Juin 2006 16:04
  • offline


Retourner vers Logiciel PC Home-cinéma