Opened 4 years ago

Closed 4 years ago

#4540 closed defect (fixed)

ADX sample count is not written to ADX header

Reported by: misty Owned by:
Priority: normal Component: avcodec
Version: git-master Keywords: adpcm adx
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

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.

Attachments (1)

patchadx.diff (810 bytes) - added by cehoyos 4 years ago.

Download all attachments as: .zip

Change History (8)

Changed 4 years ago by cehoyos

comment:1 Changed 4 years ago by cehoyos

  • Component changed from undetermined to avcodec
  • Keywords adpcm adx added
  • Version changed from unspecified to git-master

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

comment:2 Changed 4 years ago by misty

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).

comment:3 Changed 4 years ago by cehoyos

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

comment:4 Changed 4 years ago by misty

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.

comment:5 Changed 4 years ago by cehoyos

  • Status changed from new to open

comment:6 Changed 4 years ago by richardpl

comment:7 Changed 4 years ago by richardpl

  • Resolution set to fixed
  • Status changed from open to closed
Note: See TracTickets for help on using tickets.