Problem with 8bit signed output with 2.4.2 [SOLVED]

I have two computers running Windows 10. Laptop has 2.3.3 installed and will export a signed or unsigned 8bit PCM file. Desktop has 2.4.2 on it and no matter what is selected (signed or unsigned) it outputs an unsinged 8bit PCM file. The desktop had 2.4.1 on it previously which also exhibited this same problem which is why I upgraded to 2.4.2 two days ago.

Now that I understand what it is doing I can work around it but it sure was confusing for a while. I’m further processing the exported file into a 4-bit PCM for C64 DIGI files and having the file format be opposite of what was expected was interesting. Especially when the file I had done on my laptop worked fine. :slight_smile:

Just FYI

How are you selecting “8-bit signed”?
Not only do I not have that option (in either 2.3.3 or 2.4.2 on Linux), but “WAV (Microsoft) 8-bit PCM” is unsigned in the format specification.


There are some inconsistencies in the WAV format: for example, 8-bit data is unsigned while 16-bit data is signed, and many chunks duplicate information found in other chunks.

Interestingly, even Microsoft got that wrong here though the format specification can be found here:
which states:

PCM data is two’s-complement except for resolutions of 1-8 bits, which are represented as offset binary.

File->Export->Export Audio

Save as type: Other Uncompressed Formats
Header: RAW (header-less)
Encoding: Unsigned 8-bit PCM (or Signed 8-bit PCM)

I have a fuzzy memory of when I was first playing with this months ago that I had an issue with the unsigned output being ‘off’ which is why I bothered to use signed output. I don’t recall the detail though.

Ah ha!
In the absence of that I assumed you meant PCM WAV.

Let me check…

It’s working for me on Linux with Audacity 2.4.2

This (below) is a simple “ramp” signal from 0 (silence) to 1 (positive full-scale) viewed in a Hex editor.
As expected, the unsigned signal starts at 0x 80, while the signed starts at 0x 00.
How are you testing your exported files?


“How are you testing your exported files?”

By looking at them in HXD (hex editor). As you show in your screen shot is is obvious which is which. Also, both file formats output by 2.4.x are nearly identical I only saw a few ‘off by one’ difference on a quick visual inspection. The files output by 2.3.x are obviously different.

It is also painfully obvious when trying to play the DIGI file if the wrong file format was used. I modified my own code to be able to handle both signed and unsigned formats so I can work around the issue.

OK, so this is what I get with Audacity 2.4.2 on Windows 10.
The track contained one cycle of a 440 Hz sine wave.
I’ve added “.txt” to the file names so that they can be uploaded to the forum.
signed.raw.txt (101 Bytes)
unsigned.raw.txt (101 Bytes)

Thanks for looking into this. Here is the Audacity project exported from my desktop and laptop trimmed down just 32 bytes each. Both are exported as RAW 8-bit Signed PCM.

Testing 1-2-3 Signed Desk.txt (32 Bytes)
Testing 1-2-3 Signed laptop.txt (32 Bytes)

I don’t know what they are supposed to look like. Could you also export the same files as “32-bit float WAV” (that will look exactly like the waveform in Audacity).

It seems to me that it is obvious that outputting the same project with the same settings should look the same, unless there is some magic setting in Audacity that will screw up one format of export but not the other. To be clear this is the same exact file exported with the same exact settings on two different versions of Audacity and the result is different, i.e. outputting the same file as unsinged works the same way on both versions of Audacity.

I do appreciate your help though. I exported the first few seconds of the same Audacity project as you requested.
Testing 1-2-3.wav.txt (83.2 KB)

For future reference, most common audio files (including WAV) can be uploaded to the forum without changing the file extension (providing that the file size isn’t to large). “RAW” isn’t actually a file format (it’s just binary data), which is why we have to pretend that it’s a known file type.

(further reply to follow shortly …)

My follow up post after the previous one was ‘disapproved’ for some reason. I found that 2.4.2 has a Tools->Reset Configuration so I tried that and after the reset the singed 8-bit PCM exports work fine. I notice that 2.3.3 does not have this feature. I’m not sure what was reset, maybe some configuration setting present in 2.4.2 that is not in 2.3.3 which did not get set to a proper default setting when upgrading?

Sorry about that - it looks like one of the moderators misidentified it as a duplicate post (we see a lot of duplicate posts)

I was about to suggest that, though I don’t understand how that could have fixed it. My guess is that an invalid setting somewhere was causing the problem.

That’s possible.

Are you all fixed now?

Yes, thanks. It seems to be working fine now. Thanks so much for your help!

Super. I’ll close this topic now as “solved”.

For the benefit of anyone reading this later, the solution was: