0

I'm using Audacity to export a track, and there are just too many options to encode a .wav export:

  • Signed 16/24/32-bit PCM
  • Unsigned 8-bit PCM
  • 32/64-bit float
  • U-Law, A-Law
  • IMA ADPCM, Microsoft ADPCM
  • GSM 6.10
  • 32kbs G721
  • ADPCM 16/24/32, NMS ADPCM

Which is the best and why? Where can I learn more about these?

I've been exporting in 64-bit float for the past months, and I'm pretty happy with it (the file sizes are huge!). However, some streaming and distributing services (DistroKid, for example) won't take it and instead I used Signed 32-bit PCM.

But this causes a problem: for some reason, exported tracks that wouldn't have distortion with clipping (using 64-bit float), now do and I get a lot of clipping sounds when using Signed 32-bit PCM. The solution I found is to simply lower the volume of the track before exporting. This didn't happen in my previous laptop, so I wonder what is going on and if you have any suggestions to make the most of a .wav export.

By the way, this is the options I have (is there a better format than WAV?):

enter image description here

Improve this question
9
  • 3
    I believe this question is probably more fitted for sound.stackexchange.com. In any case, you're getting distorsions probably due to the playback backend that uses a wrong reference. Frankly, unless you're doing some high-end mastering, there's really no need to use 64bit. Nowadays, using 32bit float is pretty standard. For obvious reasons, avoid 8bit. 32bit signed doesn't provide better benefits than the float counterpart. Gsm should be avoided, as g721. In any case, remember that "WAV" is actually a container, while most .wav files are uncompressed, it is technically not "a format".
    – musicamante
    Mar 27, 2021 at 21:06
  • What do you mean by "playback backend that uses a wrong reference"? Why do I get distortion on the signed 32-bit PCM and not on the 64-bit float?
    – sam wolfe
    Mar 27, 2021 at 21:11
  • 1
    It could be a playback problem, if the player's audio decoder isn't correctly programmed, but generally speaking integer based wave samples have higher dynamic range (which often results in "louder" sound, for physical reasons, but also depending on the decoder). To simplify, with 16bit, the range for each sample is -32768/32767, while in 32bit it's -2^31/(2^31-1), and since most decoders/DA converters are not really used to that sampling, the result is that they often sound louder (and close to distortion). Float sampling is more coherent, due to the nature of its sampling and precision.
    – musicamante
    Mar 27, 2021 at 21:29
  • Note that this is a huge oversimplification. As said, you should move to sound.SE. In any case, using 32bit integer is really pointless, especially with nowadays technology and standards. See 32 bit float files explained, it doesn't cover all formats, but it's a good start.
    – musicamante
    Mar 27, 2021 at 21:29
  • 2
    I didn't suggest to export in 16-bit, I only said that using 32bit integer is pointless, and you should prefer 32bit float instead (at least, you'd get actual benefit from such size/length ratio). Flac is just a data compression algorithm, it doesn't alter the audio content: in fact, if you convert a flac file created from a wave file back to wave again, you'll get the exact same data of the original (unless you used some custom settings for the conversion). As long as you're using uncompressed (as in lossless) formats, there's no difference; what matters are bit depth and frequency.
    – musicamante
    Mar 27, 2021 at 21:55

1 Answer 1

Reset to default
4

This is expected behaviour. There is a fundamental difference between integer and floating formats:

  • Integer represents always a fixed amplitude range, generally interpreted as [-1, 1], uniformly covering this interval with e.g. 65536 equal steps in case of 16-bit. that means that any value outside of the range cannot be represented at all, because there simply aren't any more 16-bit values available. As a result, it's imperative that you keep within the 0 dB headroom.
  • Floating point gives you an effectively unlimited amplitude range: peaks of > 0 dB can still be represented, it merely results in less resolution (but that's hardly an issue, because the signal strength will then mask the resulting quantisation noise). That's why DAWs, which nowadays all use floats internally, have no problem cranking up a track to +30 dB or something, as long as the master is scaled down again.

Even if exporting to float, it is good practice to limit the master amplitude to 0 dB. Do this by selecting a suitable master level (most DAWs give you an option to automatically normalise the level, i.e. scaling the level such that the highest peak it just at -0 dB).
You probably also want to use compressor / limiter / soft-clip plugins, to not have all your headroom eaten up by a few freak transients. (But don't overdo it.)

If you did everything right, then it hardly matters at all whether you export as 64- or 32-bit float, or 24-bit integer. I would generally pick the latter, because it's the smallest that has essentially perfect quality. Only use float formats if you don't want to bother with normalising/limiting, can afford the extra space, and know that the file will never need to be played on consumer devices.

16 bit integer has a significantly lower optimal SNR than the former formats, but it's still good enough for most purposes, provided you use proper dithering.

All the other formats are basically obsolete. E.g. μ-Law (here misspelled as U-law) is a nonlinear encoding that's more or less a poor man's floating-point, but these kind of formats are only relevant for old embedded devices – essentially, telephony. Ok for live speech, rubbish for rendered music.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.