Last byte of unsigned 8bit PCM export is a zero

Hi,

Not a major thing, but the last byte of the file (unsigned 8bit PCM export is zero, both Wav and AIFF). Unsigned 8-bit should end with 1/2 of 255 as in the audio file or is the last byte not part of the sound it self? Using it in my 8-bit sample player project it causes a click. I can easily remove it so not a huge deal, but I wonder if it is correct.

1 Like

I couldn’t duplicate that.

First, I tried exporting a random file as 8-bit WAV. I looked at it with a hex editor and there was non-zero metadata at the end. Then I tried removing the metadata with Mp3Tag. There were still some remnants of the metadata but the last few bytes were zeros. That would create a click if converted to audio.

In both of the above cases, opening in Audacity and zooming-in to where I could see the individual samples the audio faded to silence with no glitch at the end. (The metadata was correctly not converted to audio.)

Next, I generated a silent file with no metadata. Following the header is a file full of bytes with a value of 80 hex (128 decimal) including the last byte. (I’m not sure why it’s not dithered, since I have dither enabled…)

Opening the 48kHz 16bit original, converting it to wav 8bit 32 kHz, closing and opening it again it does not click audibly in Audacity, but the last byte is still zero according to the “Hex fiend” file reader. Saving it as AIFF 32kHz 8-bit, closing it and opening it there is an audible click at the end (with Audacity) and the last byte is zero here also. I also tested without changing sample frequency, but the last byte is still zero. I couldn’t upload AIFF, so I renamed it as txt. The other one is the 16bit original saved as wav.

Bass sample C4 32kHz USig 8bit.txt (3.5 KB)

WAV files specify that chunks must be word-aligned, so there is often padding (zeros) at the end to meet the word boundary. The “data” block is preceded by a 4 byte “size”, which says how many bytes of data there are. Any zeros padding the end of the data are not counted in the data and should not affect playback because it is not part of the audio.

The file that you posted does have an actual 00 data byte at the end. How did you make that file?

I used a 16bit PCM sample, shortened in both ends with Audacity, then Exported it in both 16bit PCM and 8 bit PCM with Audacity “Export Audio”. When I play back the 8bit aiff, exported with Audacity it clicks at the end (played back in Audacity). The 16bit aiff, wav and 8-bit wav does not.So what you are saying is that the zero at the end is padding. Then I should simply reject any zeros at the end always.

I can’t reproduce that. It may be a bug in the version / platform you are using.

Ok. Thanks.

(I used Audacity 3.7.7, updated yesterday. Running it on M4 MacOs 15.7.2 Sequoia.)

Is the problem repeatable with clearly defined steps? For example, if you generate a Tone with a length of just a few samples and export it in a specified format?

I can’t test on Sequoia, but if you can provide clear and precise steps, then I can test with 3.7.7 on Linux to see if it is reproducible here.

I have worked around it and maybe the padding is correct (odd bytes not allowed). It was confusing that Audacity playback of the 8-bit file also ended with an audible tick/click. That is why I assumed that the last byte zero was an error.

If you want to test it, open the 16bit wave file attached (same as I attached before). Then “Export Audio”. Select format AIFF (or WAW). Mono. 32000Hz. Unsigned 8-bit PCM. Export Range:-Entire project. Export.

Om my MAC only the AIFF ends with an audible click in Audacity, but both 8-bit AIFF and 8-bit WAV gets that last byte = zero which I now simply remove in my little program using it.

8-bit unsigned 32kHz AIFF does give me one extra sample, but it is at “silence” level.

I don’t get the extra sample in other formats, and I don’t get the extra sample if the sample rate is not changed on export.

I don’t get the extra sample if I reduce the original file length by 1 sample (deleting the final sample).

So this does appear to be a genuine bug, albeit an edge case.
If you wish to log the bug officially, this is the place to do so: GitHub · Where software is built (GitHub registration required, but it’s free).