[FFmpeg-devel] ALAC encoder is not bitperfect

[Baptiste Coudurier]

On 4/13/2009 1:50 PM, Justin Ruggles wrote:
> Jai Menon wrote:
>> On 4/13/09, Brent Huisman <brenthuisman at gmail.com> wrote:
>>> Hey Jai,
>>>
>>>  I've used several different builds, including the new ffmpeg 0.5. Any
>>>  and all versions I tried exhibit this behaviour. Also any and all
>>>  source wave files I use have this. Have you tried bitcomparing
>>>  yourself?
>> Yes, and the output is bitexact as far as I have seen. Please specify
>> what exactly you are using to bitcompare. If its foobar2k bitcompare,
>> then sadly thats a bug in fb2k's mp4 demuxer and should be reported to
>> them. I think Justin posted something in this regard to HydrogenAudio.
>> FFmpeg'a alac encoder writes out the no. of samples in every frame
>> correctly which fb2k discards and instead pads the frame with zeroes.
>> Try checking the bitexactness using itunes or ffalac.
> 
> The specific issue seems to be a combination of our mp4 muxer and how
> fb2k handles it, but ALAC decoders other than fb2k read the actual ALAC
> frames to determine the number of samples, while fb2k uses info from the
> mp4 container.
> 
> Here is a quote on Hydrogenaudio from a user named Gregory S. Chudov:
> 
> ** start quote **
> There are two places in mp4 container, where the length is stored.
> 
> First place is in moov.mvhd chunk (movie header).
> iTunes encoder writes the approximate number of samples there.
> ffmpeg encoder writes the approximate length in milliseconds.
> This is not very reliable field and is ignored by fb2k.

Well mvhd is scaled according to global timescale which is 1000, and set
accordingly.
I guess sample rate could be used if the file has only one audio track.

But in any case, track time scale is sample rate and duration is in
samples number.

> Second place is moov.trak.mdia.minf.stbl.stts (sample table).
> This is where iTunes encoder stores the correct length. This is what
> fb2k uses.
> This table contains array of struct { int sample_count; int
> sample_duration }
> Total length is a sum of sample_count*sample_duration.
> Normally for iTunes-encoded file this table contains two entries.
> First entry with sample_duration=4096 and sample_count=total_samples/4096
> Second entry with sample_duration=total_samples%4096 and sample_count=1
> For ffmpeg, this table sadly contains only one entry, so the total
> sample length is rounded up to a multiple of 4096.
> ** end quote **

Is alac frame size different for the last sample ? If not, then it is
_wrong_ to set it differently.

'stts' contains duration for each sample independantly.

[...]

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer                                  http://www.ffmpeg.org