ADX sample count is not written to ADX header

[Misty De Meo]

When FFmpeg encodes ADX files, it hardcodes the sample count to 0: ​http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/adxenc.c;h=7736d09b5673f76d112f7fcf21d3e3f304a6080b;hb=HEAD#l111

The sample count is a 32-bit big-endian value located at 0xC in the header. Most ADX decoders rely on the sample count in order to be able to play files, and don't infer it from other properties as FFmpeg does; as a result, other ADX decoders assume that any files encoded by FFmpeg are 0 length in duration.

[Carl Eugen Hoyos]

Do I understand correctly that these players do not play the adx files produced by FFmpeg at all?
Please test attached patch.

[Misty De Meo]

Do I understand correctly that these players do not play the adx files produced by FFmpeg at all?

That's correct.

Unfortunately, -1 is still interpreted as empty in vgmstream. adx2wav crashes before writing any decoded audio, and my own player keeps working past the end of the file (oops).

[Carl Eugen Hoyos]

Could you provide a "correct" sample or (much better) explain how the correct value can be calculated after encoding the whole file?

[Misty De Meo]

You can calculate the size given the stream offset and the final size of the file, by doing:

(file_size - stream_offset) / channel_count / frame_size * samples_per_frame

For example, I encoded a stereo file in FFmpeg which ended up at 8643060 bytes long; according to the header written by FFmpeg, the first frame is located at 36 bytes, and the frame size is the standard 18 bytes containing 32 samples, so the file is 7682688 samples. If I use a hex editor to change the 4 bytes starting at 0xC to 00753A80 then all three decoders I've tested with interpret the file correctly.

[Elon Musk]

Should be fixed in 6c8a05268cfe2235e37a28a5cc5b20f6c16b90ad.