[FFmpeg-devel] Help with adding new adpcm decoder

Michael Niedermayer michael at niedermayer.cc
Tue Nov 22 16:04:46 EET 2016


On Tue, Nov 22, 2016 at 12:47:04PM +0100, James Darnley wrote:
> I want to add a decoder for a game's music, specifically Falcom's Xanadu
> Next.  I think the audio could be decompressed by adpcm_ms but the
> problem comes from the rest of the format.
> 
> The file starts with a riff wave header that lies about being pcm and
> other values, but I can force the decoder with ffmpeg.  In the data
> block (which has an incorrect size) the data is divided into frames and
> subframes of constant size (except for the last one).
> 
> The frames have an 8 byte header.  The first 4 being a little endian
> number of the bytes in the frame, which is always 20480 0x5000 (except
> for the last frame).  I am not sure of the meaning of the remaining 4
> bytes.  In reality the header is almost always these bytes:
> 00 50 00 00 20 3e 01 00
> 
> The subframes are each 2048 bytes.  Each subframe leads with the
> adpcm_ms specifics:
> - two 1-byte 'block_predictor' for left and right channels
> - two 2-byte 'idelta' values
> - four 2-byte starting samples
> (14 bytes)
> 
> 10 subframes in each frame.  A quick and crap diagram:
> 
> +---frame
> | 8 byte header
> +---subframe(s)
> |  2048 bytes
> | [2048 bytes]
> 
> I can probably successfully decode with the existing code in
> libavcodec/adpcm.c by adding a new codecand a few new cases to existing
> functions.
> 
> My trouble is with how the AVPackets are created.  The decoder gets
> packets of constant 4096 bytes.  The 8 byte frame header means the
> packets drift from the subframes.  As a concrete example, the 2nd
> 2048-byte subframe would be split between the 1st and 2nd packets (just
> 8 bytes in the 2nd)
> 

> Is it the wave demuxer that splits the packets up like this?  I don't
> think I can change that because the riff header lies about the data within.

block_align controls how the wav demuxer splits packets, setting it
correctly could be one solution

but maybe writing a new demuxer is cleaner, wav is not a format
with packets that contain size values like the 8 byte headers

the 3rd option is a AVParser to take the output from the wav
demuxer and turn it into properly packetized data


[...]


-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20161122/502a947a/attachment.sig>


More information about the ffmpeg-devel mailing list