Quelles spécifications techniques doivent être définies pour la musique?


11

J'écris la musique d'un jeu vidéo. À un moment donné, je vais devoir travailler avec les programmeurs pour déterminer les spécifications techniques des fichiers audio que je vais leur remettre. De quels types de détails allons-nous avoir besoin pour parler?

Par exemple, je pense que nous devrons peut-être régler quelques questions:

  • Dans quel format les fichiers audio doivent-ils être?
    • Non compressé? Sans perte? Comprimé?
    • Quel est l'équilibre entre l'audio de haute qualité et les petits fichiers?
  • À quel point la musique doit-elle être forte?
    • Quel devrait être le niveau de volume moyen de chaque piste?
    • Quel devrait être le niveau de volume le plus fort?
  • Quelle devrait être la distribution de fréquence?
    • Par exemple, devrais-je m'efforcer d'écrire de la musique qui n'a pas beaucoup de basses pour que les sons graves soient facilement entendus?

Les questions auxquelles j'ai pensé sont-elles importantes à poser? Y a-t-il d'autres questions dont nous devrions discuter?


Cela semble très large ...

5
Je pense que c'est une excellente question, car elle constituerait une ressource utile pour les autres.
Ingénieur

2
un point qui me vient à l'esprit est la priorité des sons. Cela est assez évident dans un jeu comme Diablo où vous avez beaucoup d'effets engendrant tous en bombardant vos haut-parleurs en même temps. Afin d'éviter qu'il ne devienne du bruit lorsque de nombreuses actions se déroulent, vous devez réduire certains des sons les moins importants tels que les pas et l'ambiance afin d'en faire des sons importants comme des sorts clés auxquels le joueur doit réagir. le volume d'entre eux une fois que le combat est assez bas. Cela dépend également des capacités matérielles du nombre de canaux que vous pouvez utiliser.
ScrambledRK

Réponses:


6

Si je comprends bien, vous avez ici deux questions différentes:

  1. Quels types de considérations techniques (comme dans la programmation) devraient être définies?

  2. Quels types de considérations techniques (comme dans l'ingénierie audio) devraient être définies?

Pour les deux questions, le mieux est de demander au responsable. Pour le premier, ce pourrait être le programmeur audio principal, tandis que pour le second, ce pourrait être le directeur audio.

Maintenant, je suppose que puisque vous posez cette question ici, vous faites partie d'une petite équipe sans de tels rôles, et votre programmeur ne sait probablement pas de quoi vous parlez, donc je vais répondre avec quelques informations générales des lignes directrices qui pourraient fonctionner pour la plupart des projets. Mais en tout cas, je ne recommanderais pas de prendre des décisions par vous-même. Discutez avec les autres membres de votre équipe pour parvenir à une conclusion.

Cela dit, parlons d'abord de quelques considérations techniques (programmation).

  • Habituellement, le format dans lequel vos fichiers audio seront distribués est déjà déterminé par la plateforme ou le moteur de jeu que vous utilisez. Si vous envisagez de multiplier les plates-formes, il est probable que chaque plate-forme aura des répertoires de ressources complètement indépendants, et les caractéristiques des fichiers audio peuvent être différentes pour chaque plate-forme.

    Par exemple, vous devrez peut-être rendre les fichiers Ogg Vorbis pour Android, MP3 ou AAC pour iOS et WMA pour Windows.

    Parfois, même le format dépend de l'objectif de chaque fichier. Alors qu'iOS joue bien avec les fichiers MP3 et AAC à toutes fins, PlayStation Mobile nécessite MP3 pour BGM, mais ne prend en charge que PCM non compressé ou Microsoft ADPCM.

    Demandez à votre programmeur dans quel format les fichiers doivent être.

  • La plupart du temps, les spécifications de base des fichiers seront déjà définies, alors assurez-vous de demander à votre programmeur à ce sujet. Par exemple, les fichiers BGM sont généralement distribués en stéréo, tandis que les fichiers SFX et vocaux sont généralement distribués en mono (afin qu'ils puissent être facilement positionnés à l'intérieur du jeu)

  • Pour les débits binaires et autres paramètres, encore une fois, ils dépendent généralement du moteur ou de la plate-forme. Si vous avez une certaine liberté ici, considérez que les données sonores sont généralement la plus grande composante d'un jeu, et si le jeu doit être distribué via des téléchargements numériques, votre programmeur (et vos clients) vous remercieront si vous faites les fichiers aussi petits que possible.

    Si vous distribuez sur un support physique, la taille de distribution maximale est prédéterminée et vous devrez négocier sérieusement avec le reste de l'équipe de création de contenu.

  • Certains jeux nécessitent que vos sons (principalement BGM) soient bouclables; d'autres jeux nécessitent que vos sons soient soumis à des contraintes de timing strictes (comme les jeux de rythme). La plupart des schémas de compression avec perte ajoutent un silence de remplissage au début et à la fin de la piste, ce qui peut rompre les boucles et un timing strict. Discutez de ces problèmes avec votre programmeur.

Il existe trop de façons de compresser l'audio, donc ce que je vous recommande est de sortir une version principale de chaque fichier son en PCM non compressé à 44,1 kHz 16 bits stéréo, puis d'utiliser ce fichier pour créer les fichiers réels pour chaque plate-forme. (De manière optimale, vous pouvez créer un script de transformation qui peut être appliqué à chaque fichier afin que vous n'ayez pas à reconvertir chaque fichier chaque fois que vous apportez une petite modification dans le fichier maître).

Maintenant, en termes de considérations techniques (comme dans l'ingénierie audio), votre programmeur ne s'en souciera probablement pas, vous aurez donc plus de liberté dans ce domaine. Vous pouvez cependant faire certaines choses pour faciliter la vie de votre programmeur:

  • Tous les sons du jeu devraient avoir une intensité normalisée. À tout le moins, tous les fichiers BGM devraient avoir la même intensité entre eux, et tous les fichiers SFX devraient avoir la même intensité entre eux. Ne forcez pas votre programmeur à modifier les volumes à l'intérieur du code.

  • Le code de lecture est très limité et ne peut généralement faire qu'une amplification linéaire. Pour cette raison, entre une intensité sonore élevée et faible, une intensité élevée peut être préférée, car la réduction du volume pendant la lecture conduit généralement à de meilleurs résultats que l'amplification. Il est difficile de dire quelle devrait être la sonie exacte, mais en règle générale, plus l'amplitude globale de crête à crête est élevée, mieux vous utilisez la plage d'échantillonnage.

    Vous voudrez peut-être charger d'autres jeux et jouer leurs sons à leurs paramètres de volume maximum et comparer vos sons avec les leurs.

  • En termes d'égalisation, je dois dire que cela dépend vraiment des autres sons que votre jeu aura. En plus d'en discuter avec le directeur du son, vous voudrez peut-être également prendre en compte le matériel de lecture que vous utiliserez: alors que les ordinateurs de bureau peuvent avoir une grande variété de matériel de lecture, les appareils portables ont généralement de très petits haut-parleurs, et vous voudrez peut-être compenser cela. Les machines d'arcade ont également des exigences très différentes.


Une chose à souligner, pour SFX, je déteste les fichiers stéréo. Je dois les combiner en mono dans le moteur pour pouvoir les insérer correctement dans le moteur de son 3D. En conséquence, tous les SFX peuvent être d'origine, par exemple les sons foley sont mono.
rioki

2

Je fais la différence entre deux situations, ce que je garde pendant le développement et plus tard (stockage) et ce que je mets dans la livraison finale.

Pour le stockage, j'utilise la meilleure qualité possible, c'est-à-dire pour un format audio sans perte. Tant que la compression est sans perte, cela n'a pas vraiment d'importance; WAV ou FLAC fera l'affaire. Je suis fondamentalement OK avec un enregistrement 44,1 kHz / 16 bits et le volume devrait être "naturel" autant que possible, donc un enregistrement fondamentalement original avec un gain minimal si nécessaire. (Si vous le voulez vraiment, vous pouvez opter pour des enregistrements à 96 kHz ou 192 kHz.) La taille n'a pas vraiment d'importance, les disques durs ne sont pas si chers et vous pouvez toujours en ajouter plus à ce problème. La raison principale est que vous pouvez toujours compresser dans un format avec perte à partir d'un format sans perte, mais une fois que vous n'avez que des fichiers avec perte, vous ne pouvez jamais passer à une qualité supérieure.

Pour la livraison, c'est une toute autre histoire. Ici, vous devez faire des choix difficiles entre qualité, espace et vitesse. Pour les petits SFX, j'utilise des fichiers WAV car ils se chargent le plus rapidement. La musique, par contre, la taille importe, donc j'utilise normalement MP3 avec un débit binaire variable. Vous pouvez vous en tirer avec des fichiers à 64 kbps, mais c'est une question de goût. Les sons doivent essentiellement être à leur volume naturel, bien qu'ils soient équilibrés les uns par rapport aux autres. Le moteur de jeu fera alors tout ajustement nécessaire, surtout si vous faites quelque chose comme le son 3D.


Vous savez que le PCM non compressé à 44,1 KHz stéréo 16 bits va à environ 1300 kbps, non? 320 kbps d'audio non compressé sembleront hideux.
Panda Pyjama

Il est vrai que je faisais surtout référence à l'audio compressé. Le son FLAC à 128 kbps est assez fin.
rioki

"kbps" comme paramètre d'encodeur n'a aucun sens pour FLAC ou d'autres encodeurs sans perte. La taille par rapport à la qualité (sonore) n'a de sens que pour la compression avec perte. Êtes-vous sûr que c'est FLAC dont vous parlez?
Panda Pyjama

Vous avez raison, c'est le programmeur qui parle. Le "bitrate" est basé sur l'enregistrement original. Ce que je ferais normalement à 44 kHz, ce qui est bien. Vous pouvez vous faire sodomiser et faire des enregistrements à 96 kHz ou 192 kHz. Je vais changer ce que je voulais vraiment dire ...
rioki

1
44KHz, 96KHz et 192KHz sont des "taux d'échantillonnage", pas des "débits". Ce n'est pas une bonne idée de les mélanger parce que sampling rate * sample size * channel count = bitrate. C'est pourquoi le débit binaire pour la stéréo 16 bits à 44,1 kHz est exactement de 1411200 bits / s. 320kbps de son stéréo 16 bits devraient être échantillonnés à 10KHz, et donc ma remarque "semblera hideuse".
Panda Pyjama
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.