Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Changing the endiannes of a 16bps uncompressed WAV file (Read 1188 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Changing the endiannes of a 16bps uncompressed WAV file

Hello. I've ripped some PCM sounds from some Flash games but they do not sound right. The reason is that they are encoded as native endian and my processor plays it right but JPEXS FFDEC does not use the correct endianness. How can I change the endiannes of a 16bps uncompressed WAV file?

Re: Changing the endiannes of a 16bps uncompressed WAV file

Reply #1 –
Wave is little-endian - Microsoft
AIFF is big-endian - Apple

This sounds like a problem with the tool you're using and nothing else and I can't help you beyond that.  You can try treating it as raw then correct the endian in common software like Audacity.

Re: Changing the endiannes of a 16bps uncompressed WAV file

Reply #2 –
JPEXS FFDEC decompiles the Flash and then what? Are you sure what it exports is indeed WAVE and not something else with wrong file extension?

If it can export big-endian AIFF, then do that. And then compress with FLAC (which by default removes the information that it was ever an AIFF), or wavpack -r.

Re: Changing the endiannes of a 16bps uncompressed WAV file

Reply #3 –
Quote from: Chibisteven on
Wave is little-endian - Microsoft
AIFF is big-endian - Apple

This sounds like a problem with the tool you're using and nothing else and I can't help you beyond that.  You can try treating it as raw then correct the endian in common software like Audacity.

Quote from: Porcus on
JPEXS FFDEC decompiles the Flash and then what? Are you sure what it exports is indeed WAVE and not something else with wrong file extension?

If it can export big-endian AIFF, then do that. And then compress with FLAC (which by default removes the information that it was ever an AIFF), or wavpack -r.

Native endian means the PCM will be played with the endianness of the processor. So, while it plays correctly on my processor, it can play wrongly on another processor. That's the nature of native endian. This situation is not the fault of JPEXS FFDEC as the definition can be interpreted in both ways, though it would be better if it gave an option to select the correct endianness. Changing the file extension did not change anything as I expected, and interestingly changing the sound type from native endian to little endian did not change anything too.

So, how can I change the endianness of the sound data (not the file) of a 16bps uncompressed WAV file?

Re: Changing the endiannes of a 16bps uncompressed WAV file

Reply #4 –
Jeez, Klymins. Are there no real problems you'd like to address? I know you're not simply trolling, but there are just so many discussions with little to no actual value...

Re: Changing the endiannes of a 16bps uncompressed WAV file

Reply #5 –
Quote from: Big_Berny on
Jeez, Klymins. Are there no real problems you'd like to address? I know you're not simply trolling, but there are just so many discussions with little to no actual value...

Almost all of my questions (including this) are to gain an actual value. Here's the ring sound that I ripped from Ultimate Flash Sonic and want to examine in the spectrogram but can't because of the wrong endianness:

Re: Changing the endiannes of a 16bps uncompressed WAV file

Reply #6 –
Your file sounds just as silly when endianess is converted. It looks like 8-bit stereo file.

Re: Changing the endiannes of a 16bps uncompressed WAV file

Reply #7 –
Quote from: Case on
Your file sounds just as silly when endianess is converted. It looks like 8-bit stereo file.

This is not correct at all. I'm currently trying to convert the endiannes.

Re: Changing the endiannes of a 16bps uncompressed WAV file

Reply #8 –
I couldn't convert the endiannes, how can I do this?

Re: Changing the endiannes of a 16bps uncompressed WAV file

Reply #9 –
I gave you the corrected file, at least it sounds sensible. But here's a file with endianess changed. You do that by simply swapping the byte order of the 16 bit words. You as an audio codec developer could easily write a program to do it.

Re: Changing the endiannes of a 16bps uncompressed WAV file

Reply #10 –
Quote from: Case on
I gave you the corrected file, at least it sounds sensible. But here's a file with endianess changed. You do that by simply swapping the byte order of the 16 bit words. You as an audio codec developer could easily write a program to do it.

Endiannes of the bytes should be changed, not the bits. (I'm actually not sure, maybe the opposite, I was being hurry, sorry.) Also, I'm not an audio codec developer, I just hope I'll be able to improve some codecs in the future. And, I can't write a program to do that because I don't know the header structure of the WAV files, including the length.

Re: Changing the endiannes of a 16bps uncompressed WAV file

Reply #11 –
Bytes remain identical, order of bytes is different. See https://upload.wikimedia.org/wikipedia/commons/5/5d/32bit-Endianess.svg.

Edit: anyway, you can use command ffmpeg -i <sourcefile> -f s16le -c:a copy output.raw
to get a RAW file, then you can use Audacity and its File -> Import -> Raw to read the output.raw as any format you wish. You could do the same with the .wav too, but the header would cause a pop at the beginning.

Re: Changing the endiannes of a 16bps uncompressed WAV file

Reply #13 –
MediaInfo says: 5512Hz, 1 Channel, PCM (little / signed).  But little endian is what's normal for a WAV file so that might be wrong.

Try importing into Audacity raw data.  You can try little or big endian to see if one works.

When you import as raw data the header will be converted to audio (noise) so you can either delete the noise in Audacity, or try an offset of 44 to skip-over the header.   You can also try an offset of 0 or 1 (or 44 or 45) because that can also put the bytes in the wrong order.

If you get it right in Audacity you can export it as a normal WAV file (or other format).

Re: Changing the endiannes of a 16bps uncompressed WAV file

Reply #14 –
It turned out that this is an 8-bit mono file:

(I noticed that the SWF file actually says it's 8-bit, so JPEXS FFDEC treats it as 16-bit in all conditions and that's a big problem.)

Re: Changing the endiannes of a 16bps uncompressed WAV file

Reply #15 –
For those who don't know headers, I guess it is easier to use e.g. flac or wavpack/wvunpack to compress it and then write it to raw.
But if it is 8-bit mono/stereo or 16-bit mono, then even a 46-byte header would be an integer number of samples.
 

Re: Changing the endiannes of a 16bps uncompressed WAV file

Reply #16 –
Importing (into Audacity) as 8-bit unsigned seems to work better and of course there's no endianess with 8-bit mono file so that eliminates the endianes issue, but I don't know what it's supposed sound like.

How does the playing time compare to what you expect?

Of course 8-bits also doubles the number of samples so it doubles the playing time.   

Of course if the sample rate is wrong or the number of channels is wrong that also messes-u the speed & playing time.

Re: Changing the endianness of a 16bps uncompressed WAV file

Reply #17 –
Quote from: DVDdoug on
Importing (into Audacity) as 8-bit unsigned seems to work better and of course there's no endianess with 8-bit mono file so that eliminates the endianes issue, but I don't know what it's supposed sound like.

How does the playing time compare to what you expect?

Of course 8-bits also doubles the number of samples so it doubles the playing time.   

Of course if the sample rate is wrong or the number of channels is wrong that also messes-u the speed & playing time.

I couldn't understand you. The last file I've shared is correct.

In summary: I was wrong for assuming that the problem was caused by the endianness (it was caused by the bit depth).