ac3enc.dll: AC3 is about 0.25% too short if input WAV is 44100Hz

[Liisachan]

Sorry if this is a known problem, but I think something is strage in BeSweet's WAV->AC3,
if the sample rate is 44100Hz. Let me report this as something I can always reproduce. Thank you in advance.

Demo: 1567 KB (http://park14.wakwak.com/~flower/demo.zip)

How to Reproduce the Problem
(1) Observe that 10sec.wav in demo.zip is 441001 samples @ 44100Hz
(2) BeSweet -core( -input 10sec.wav -output 10sec.ac3 -logfilea "debug.log" ) -ac3enc( -b 192 )
(3) The resulted AC3, 10sec.ac3, is 439820 samples @ 44100Hz, i.e. 0.27% too short.

I did the same test for a longer WAV too, that is 177877056 samples @ 44100Hz. The resulted AC3 was 177468267 samples @ 44100Hz, 0.23% too short. The original is 4033.49sec, the resulted is 4024.22sec, so eventually out of sync by 9.27 sec--too large to ignore.

Note: This phenomenon doesn't seem to happen if WAV is 48000Hz.

<edit>
I read "ac3enc.dll creates (almost) useless ac3 streams. don't use it to encode things you care for. it's there only for test purposes." but it't not like I'm going to use it for real encoding. I just tested it and found this.
</edit>


BeSweet v1.5b29 by DSPguru.
--------------------------
Using AC3enc.dll v1.20 (Feb 18 2004) by Fabrice Bellard (http://ffmpeg.org).

Logging start : 02/03/05 , 14:35:36.

BeSweet -core( -input 10sec.wav -output 10sec.ac3 -logfilea debug.log ) -ac3enc( -b 192 )

[00:00:00:000] +------- BeSweet -----
[00:00:00:000] | Input : 10sec.wav
[00:00:00:000] | Output: 10sec.ac3
[00:00:00:000] | Floating-Point Process: No
[00:00:00:000] | Source Sample-Rate: 44.1KHz
[00:00:00:000] +------- AC3ENC ------
[00:00:00:000] | Bitrate method : CBR
[00:00:00:000] | AC3 bitrate : 192
[00:00:00:000] | Channels Mode : 2.0
[00:00:00:000] | Error Protection: Yes
[00:00:00:000] +---------------------
[00:00:10:000] Conversion Completed !
[00:00:10:000] Actual Avg. Bitrate : 191kbps
[00:00:01:000] <-- Transcoding Duration

Logging ends : 02/03/05 , 14:35:37.

[Liisachan]

Hi, I got this suggestion.

See Table 5.18 "Frame Size Code Table" in page 48 of the specs,
http://www.atsc.org/standards/a_52a.pdf

For 192Kbps, 44100Hz, the "words/syncframe" can be
417words/syncframe(010100)
or
418words/syncframe(010101)

A binary editor shows that the actual value used in the AC3 file encoded by BeSweet is 417 (010100), and this gives us a hypothesis--shouldn't this be 418 instead of 417?

If we confused 417 and 418, the theoretical error would be 2.39%, while the observed (actual) error is 2.30%--about the same.
This can be coincidence, and may be newbie's wild guess, but just in case it might help find a clue...

[Liisachan]

Trying to make a patch for ac3enc.c, around line 860
( /* for now we do not handle fractional sizes */ )

This is how it is:

If we try to convert WAV (44100 Hz, 2ch, 16bit, 10sec) into AC3 at 192000bps with ffmpeg, the result will be:
44100*2*10 / 1536 (samples) = 574.21875 frames
574 frames = 574 * 417(words) = 239358 bytes = 1914864 bits

Then, when you play the resulted AC3 at 192 kbps as the header says, the duration is,
1914864 / 192000 = 9.97325 sec

The original WAV is 10 sec, while the resulted AC3 is played as 9.97 sec, i.e. about 0.25% too short as I'm repeating.

Cause:
Fixed 417 words mean 1 frame = 1536 samples = 834 Bytes, hence 44100 samples = 191559 bits --> 191.559 kbps

If you play something encoded at 191.559 kbps as 192 kbps, obviously the result is slightly too short in duration, in other words, the audio plays too fast, about 0.25% too fast.

What should be done in this case:
Mix 417-word frames and 418-word frames: Use two 417-word frames + forty seven 418-word frames periodically.
That makes every 49 frames contain 417*2+418*47 words = 327680 bits,
and 49 frames = 75264 samples = 1.706666 sec,

327680 bits / 1.706666 sec = 192000 bps