2009-09-06 5 views
2

Il existe une tonne de tutoriels et de blogs sur l'enregistrement du son à partir de .NET. J'ai lu et compris fondamentalement les différentes options, mais je ne suis pas sûr de l'approche sera la plus simple tout en répondant à mes besoins:Enregistrement sonore en .NET avec certaines exigences spécifiques

Minimal

  • Démarrage et arrêt de l'enregistrement contrôlé par un programme .NET
  • enregistrement du microphone par défaut fichier
  • Réduire au minimum les exigences sur l'ordinateur de l'utilisateur final (c.-à-idéalement aucune exigence pour DirectX)
  • dernière
  • Enregistrer dans un fichier commun, comprimé Format

Idéalement

  • supprimer les zones calmes de l'enregistrement
  • DETENTE/arrêt de l'enregistrement en fonction sur la présence d'entrée audio (enregistrement uniquement lorsque il y a quelque chose à enregistrement)
  • Possibilité de reprendre l'enregistrement, en ajoutant au fichier précédemment enregistré

Je peux étudier les détails de la mise en œuvre et je suis juste à la recherche de conseils sur le meilleur chemin pour commencer, compte tenu de mon ensemble d'exigences.

Répondre

4

Je préfère enregistrer l'audio en utilisant les fonctions de l'API waveIn * (waveInOpen etc.). Bien que cette API soit ancienne (plus de 15 ans) et légèrement plus difficile à utiliser que vous ne le souhaiteriez, elle peut faire tout ce que vous mentionnez ci-dessus (sauf une), ne nécessite pas DirectX et fonctionne sur toutes les versions de Windows. retour à Windows 95 (bien que .Net ne fonctionne sur rien avant Windows 98), même en incluant Windows Mobile (ce dernier fait a soufflé mon esprit quand je l'ai découvert). La seule chose qu'il ne gère pas est l'enregistrement dans un format de fichier compressé commun (mais je ne pense pas que l'enregistrement avec DirectSound - l'autre option majeure - gère cela non plus). Cependant, il existe un certain nombre de bibliothèques compatibles .Net qui peuvent gérer cette exigence pour vous (NAudio est bien recommandé, même si je ne l'ai jamais utilisé). Un des avantages de l'enregistrement avec waveIn * (le même avantage revient à DirectSound) est que vous enregistrez en mémoire (par opposition à l'enregistrement direct sur un fichier), il est donc facile de faire ce que vous voulez avec l'audio (par ex. un fichier, dépouiller les parties silencieuses, filtrer par FFT, modifier le format, etc.). Beaucoup de bibliothèques compatibles .Net sont écrites pour traiter les tampons en mémoire à la place ou en plus des fichiers, donc avoir toujours votre audio en mémoire est un gros avantage.

Vous pouvez déclencher le démarrage et l'arrêt de l'enregistrement, mais pas de la façon dont vous le pensez. Avec l'API waveIn *, vous démarrez essentiellement l'enregistrement à partir de la source audio par défaut, et l'API commence à remplir les tampons de mémoire avec du son enregistré. Vous recevez une notification lorsque chaque tampon est rempli, et vous pouvez ensuite faire ce que vous voulez avec chaque tampon. Pour réellement enregistrer dans un fichier, vous pouvez simplement analyser chaque tampon comme il vient, et si un tampon est vide (ne contient aucun son audible) vous simplement le jeter sans écrire le contenu dans un fichier.

Voici un échantillon CodeProject qui montre comment utiliser à la fois la WaveIn * et waveout * API:

http://www.codeproject.com/KB/audio-video/cswavrec.aspx?msg=2137882

J'ai en fait travaillé avec ce projet avant en C#, et il fonctionne très bien.

+0

Nous vous remercions de votre réponse réfléchie. L'article du Code Project auquel vous faites référence est une source que j'ai regardée de plus près. Je vais laisser cela ouvert un peu plus longtemps pour voir quelles autres réponses je reçois, mais c'est certainement utile. –

+0

@MusiGenesis: Pouvez-vous élaborer sur "ne contient aucun son audible"? Est-il suffisant de ne chercher aucun échantillon avec une valeur supérieure à un certain seuil dans le tampon pour le considérer comme silencieux? Environ combien de (milli) secondes d'audio représente un tampon typique pour ce type de solution? –

+0

@Eric J: la taille de chaque buffer dépend entièrement de vous en tant que programmeur. Si vous utilisez des tampons très petits, vous pouvez faire en sorte que votre interface utilisateur réagisse visuellement aux informations audio très rapidement (c'est-à-dire avec une très faible latence), mais elle sera plus sensible aux problèmes et aux interruptions. Si vous utilisez des tampons très volumineux (comme, par exemple, 1 seconde/44100 échantillons), vous aurez moins de problèmes, mais votre interface utilisateur sera au moins 1 seconde derrière ce que vous entendez. – MusiGenesis

Questions connexes