Code: Select all
IDString "SPPK"
get TABLEOFFSET long
get FILES long
for i = 0 < FILES
get NAME string
get SIZE long
get OFFSET long
math OFFSET + TABLEOFFSET
log NAME OFFSET SIZE
next i
I am 100% confident that I got the variables correct, except for the IDString. I am not sure if I did that part right, but if you follow the path the OFFSET takes you after math, you end up at the RIFF part, which is the start of the sound data.
You can verify that the math is correct by looking at the offset of each RIFF in the file.
The 4 bytes after the RIFF are the size of the audio file which is the same above that is imputed in the SIZE variable. If you look inside the file, you will notice the first 48 bytes of each offset after calculation have similar values. These values might share the same purpose as those in the Wave Format that I have linked to below.
http://soundfile.sapp.org/doc/WaveFormat/
The only thing that seems off is the fact that this format uses 44 bytes. Not 48. The magnitude and order of the variables also do not seem to add up. Some of them do, but not all of them. If I try and assign groups of Bytes to Variables, they don't add up.
All the sound files start like this:
bytes 00-03 being the ChunkID (RIFF)
bytes 04-07 being the size of the file minus 8 bytes (The 4 bytes for ChunkID and the 4 bytes for this)
bytes 08-0B are the Format (WAVE)
bytes 0C-0F are the 1st Sub-ChunkID (fmt )
bytes 10-13 are the size of the 1st chunk which in this case is 20 bytes
*bytes 14-17 could be several things. I think bytes 16-17 are the Audio Format, but I am unsure of what bytes 14-15 would be.
bytes 18-1B might be the Frequency (Sample Rate) since it comes out to 44,100. It could also be the Byte Rate, but if it is the Byte rate, what would the frequency be?
*bytes 1C-1F I am unsure what this is. It can't be the Byte Rate because it is smaller than the suspected Frequency.
*bytes 20-23 could also be several things. I have no clue what they could be.
bytes 24-27 might be the Number of Channels (Stereo is 2 channels), and the Bits Per Sample (0x40, 64, is a multiple of 8)
bytes 28-2B are the 2nd ChunkID
bytes 2C-2F are the 2nd Chunk Size which is the size of everything after this.
I looked around and found some code from Aluigi, but it just returns the audio as static. Again, I think it has to do with the extra 4 bytes of information this file has. There is something missing.
Code: Select all
# raw to RIFF wav example
# script for QuickBMS http://quickbms.aluigi.org
set FREQUENCY long 44100
set CHANNELS long 2
set BITS long 16
get SIZE asize
get NAME filename
string NAME += ".wav"
set MEMORY_FILE binary "\x52\x49\x46\x46\x00\x00\x00\x00\x57\x41\x56\x45\x66\x6d\x74\x20\x10\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x64\x61\x74\x61\x00\x00\x00\x00"
set RIFFSIZE long SIZE
math RIFFSIZE += 36
set BLOCKALIGN long BITS
set AVGBYTES long FREQUENCY
math BLOCKALIGN /= 8
math BLOCKALIGN *= CHANNELS
math AVGBYTES *= BLOCKALIGN
putvarchr MEMORY_FILE 4 RIFFSIZE long
putvarchr MEMORY_FILE 20 1 short # wFormatTag: Microsoft PCM Format (0x0001)
putvarchr MEMORY_FILE 22 CHANNELS short # wChannels
putvarchr MEMORY_FILE 24 FREQUENCY long # dwSamplesPerSec
putvarchr MEMORY_FILE 28 AVGBYTES long # dwAvgBytesPerSec
putvarchr MEMORY_FILE 32 BLOCKALIGN short # wBlockAlign
putvarchr MEMORY_FILE 34 BITS short # wBitsPerSample
putvarchr MEMORY_FILE 40 SIZE long
log NAME 0 44 MEMORY_FILE
append
log NAME 0 SIZE
append