Opened 6 years ago
Closed 6 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)
Change History (8)
Changed 6 years ago by cehoyos
comment:1 Changed 6 years ago by cehoyos
- Component changed from undetermined to avcodec
- Keywords adpcm adx added
- Version changed from unspecified to git-master
comment:2 Changed 6 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 6 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 6 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 6 years ago by cehoyos
- Status changed from new to open
comment:6 Changed 6 years ago by richardpl
Should be fixed in 6c8a05268cfe2235e37a28a5cc5b20f6c16b90ad.
comment:7 Changed 6 years ago by richardpl
- Resolution set to fixed
- Status changed from open to closed
Do I understand correctly that these players do not play the adx files produced by FFmpeg at all?
Please test attached patch.