3 votes

Pourquoi certains fichiers wav sont-ils joués dans mon application c# directsound et d'autres non ?

J'ai une application c# qui joue des fichiers wav simples via directsound. Avec les données de test dont je disposais, le code fonctionnait bien. Cependant, lorsque j'ai utilisé des données réelles, il a produit une erreur très peu utile lors de la création du tampon secondaire : "ArgumentException : Value does not fall within the expected range".

Les wavs de test avaient un débit binaire de 512 kbps, une taille d'échantillon audio de 16 bits et un taux d'échantillonnage audio de 32 kHz. Les nouveaux wavs sont respectivement de 1152kbps, 24bit et 48kHz. Comment puis-je faire en sorte que directsound prenne en charge ces valeurs plus importantes, ou sinon comment puis-je programmer la détection de ces valeurs avant d'essayer de lire le fichier ?

j'utilise la version 9.00.1126 de DirectX, et j'ai inclus un exemple de code ci-dessous :

using DS = Microsoft.DirectX.DirectSound;  
...  
DS.Device device = new DS.Device();
device.SetCooperativeLevel(this, CooperativeLevel.Normal);  
...
BufferDescription bufferDesc = new BufferDescription();
bufferDesc.ControlEffects = false;  
...
try
{
    SecondaryBuffer sound = new SecondaryBuffer(path, bufferDesc, device);
    sound.Play(0, BufferPlayFlags.Default);
}
...

Info supplémentaire : les fichiers wav du monde réel ne se lisent pas non plus dans Windows media player, m'indiquant qu'un codec est nécessaire pour lire le fichier, alors qu'ils se lisent sans problème dans Winamp.

Info supplémentaire 2 : En comparant les octets des données de test et des mauvaises données réelles, je peux voir qu'après le chunk RIFF, les mauvaises données ont un chunk "bext", que l'internet m'informe être des métadonnées associées à l'extension audio de diffusion, alors que les données de test vont directement dans un chunk fmt. Il y a /est/ un chunk fmt dans les mauvaises données, donc je ne sais pas si c'est mal formé ou si les chargeurs devraient chercher plus loin des données fmt. Je vais voir si je peux obtenir des informations sur ce rouge bext chunk auprès des personnes qui me fournissent les données - s'ils peuvent l'enlever, mon code peut encore fonctionner.

7voto

Mark Heath Points 22240

Toutes les cartes son ne prennent pas en charge la lecture d'échantillons de 24 bits, et même lorsqu'elles le font, elles doivent souvent être ouvertes exclusivement dans ce mode. Il existe un problème similaire avec les taux d'échantillonnage. Votre carte son peut fonctionner à 44,1 kHz, auquel cas 48 kHz doit être rééchantillonné pour être lu.

J'ai écrit une bibliothèque audio .NET open source appelée NAudio qui vous permettra de connaître la fréquence d'échantillonnage et la profondeur de bits d'un fichier WAV donné. Il offre également d'autres moyens de lire l'audio (par exemple via les API Wav...) et la possibilité de rééchantillonner les fichiers à l'aide de l'objet DMO resampler.

4voto

Vinko Vrsalovic Points 116138

Outre le problème de l'échantillonnage, WAV n'est qu'un format de conteneur et l'audio peut être compressé dans une myriade de formats audio (tout comme AVI est un conteneur vidéo). Vous pouvez donc utiliser un outil comme GSpot pour savoir si votre WAV est encodé dans un format non standard et installer le codec. Winamp a plus de codecs installés par défaut que WMP, ce qui expliquerait que Winamp le joue et pas WMP.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X