I’ve been trying to find a tool to get the audio out of the
Berkeley Systems SRF format. I know the audio is IMA
ADPCM, 16? bit, mono 22050Hz, but every utility I use
on it gives really bad clipping. (There are some early
versions of the format which seem to use ordinary PCM,
but I’ll ignore those for now)
I enclose a sample of the sound, and a document I
found explaining how the file is put together – if anyone
here knows how to make this into an easily usable tool,
let me know.
Other examples can be found in games like You Don’t
Know Jack (1-4 US, the UK version and some of the
German editions) – I believe some contain JPEG graphics
data but it’s custom compressed.
ok, here are my 15-minute findings. my head is not in
the right state to
dig much more but might be a start. first of all, the
header is made of
big-endian longs, not little endian. use some kind of hex
editor to
follow my ramblings, i use hex workshop (options → byte
order → big
endian). offsets are noted in hex, btw.
first long is the format identifier, “srf1”. next long is the
size of
the file, 0×0005CA10, that’s 379408 bytes. the third long
is the size of
the header without counting these three first longs,
that’s 208 bytes.
so note that the first resource will be placed at decimal
offset 208+12,
that’s offset DC.
the header is a list of structures for defining resources
inside this
file. i’m having a headache trying to understand
the "STR " structure,
because it says there are 8 strings, but actually there
are nine, and
two of the resource descriptors point to the last two
longs of the file
(which aren’t resource space, as you’ll see). part of
this "STR "
structure is similar to the "snd " one but there are holes
in my
theory… following so many numbers (according to the
aussie aborigins,
five or more = many) makes my head hurt.
i’ll jump now to offset 74, where you can find the 4-byte
string "snd ".
next long, offset 78, is the number of sound resources in
the file, in
this case also 8. the next 24 longs are 8 groups of 3
longs each one.
each group has in this order: resource id, offset, size.
for example,
the first resource descriptor is at offset 7C, it
says “resource id
0×0000001, at offset 0×000001FC, with a size of
0×000053BC bytes”. which
means that at decimal offset 508, you’ll find a sound
resource of 21436
bytes. the last resource descriptor is at offset D0, and
says “resource
id 0×0A, at offset 347764, and is 31636 bytes long”.
Reported by: elcondormage
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent