Bug: Besweet delaying by one more frame than it should

[bobwillis]

Hi,

Here is evidence that indicates besweet may be removing the wrong number of frames, causing a larger synch problem than necessary:

Besweet 1.5b26 (also confirmed with b29).

Besweet is called with the following command:

C:\Program Files\DVD2SVCD\BeSweet\BeSweet.exe -core( -input C:\The wild bunch joined\audio\Extracted_audio_1.ac3 -output C:\THEWIL~3\audio\Encoded_audio_1.ac3 -payload -logfile C:\THEWIL~3\audio\Encoded_audio_1.log ) -ota( -d -80 )

The besweet log shows everything is ok:

BeSweet v1.5b26 by DSPguru.
--------------------------
Using azid.dll v1.9 (b922) by Midas (midas@egon.gyaloglo.hu).
Using AC3enc.dll v1.20 (Feb 18 2004) by Fabrice Bellard (http://ffmpeg.org).

Logging start : 10/28/04 , 16:40:34.

C:\Program Files\DVD2SVCD\BeSweet\BeSweet.exe -core( -input C:\The wild bunch joined\audio\Extracted_audio_1.ac3 -output C:\THEWIL~3\audio\Encoded_audio_1.ac3 -payload -logfile C:\THEWIL~3\audio\Encoded_audio_1.log ) -ota( -d -80 )

[00:00:00:000] +------- BeSweet -----
[00:00:00:000] | Input : C:\The wild bunch joined\audio\Extracted_audio_1.ac3
[00:00:00:000] | Output: C:\THEWIL~3\audio\Encoded_audio_1.ac3
[00:00:00:000] +------- AC3ENC ------
[00:00:00:000] | Bitrate method : CBR
[00:00:00:000] | AC3 bitrate : 384
[00:00:00:000] | Channels Mode : 5.1
[00:00:00:000] | Error Protection: Yes
[00:00:00:000] +---------------------
[ 399478272] Conversion Completed !
[00:00:50:000] <-- Transcoding Duration

Logging ends : 10/28/04 , 16:41:24.

If we analyse the original ac3 file (extracted_audio_1.ac3) with jsoto's delaycut.exe, we get the following info:

====== INPUT FILE INFO ========================
File is ac3
Bitrate (kbit/s) 384
Act rate (kbit/s) 384.000
File size (bytes) 399484416
Channels mode 3/2: L+C+R+SL+SR
Low Frec Effects LFE: Present
Duration 02:18:42.592
Frame length (ms) 32.000000
Frames/second 31.250000
Num of frames 260081
Bytes per Frame 1536
Size % Framesize 0
CRC present: YES
=============================================

From this we can ascertain that the resolution of the file is 32ms. In other words, we can only delay by multiples of 32ms. Since we require 80ms of delay, the closest we can get is 3 frames (=96ms). This would lead to an error of 16ms (96-80ms). This is the best besweet (or delaycut.exe) can do.

However, besweet does not remove 3 frames. If we look at the resultant besweet encoded_audio_1.ac3 file with jsoto's tool, we get the following info:

====== INPUT FILE INFO ========================
File is ac3
Bitrate (kbit/s) 384
Act rate (kbit/s) 384.000
File size (bytes) 399478272
Channels mode 3/2: L+C+R+SL+SR
Low Frec Effects LFE: Present
Duration 02:18:42.464
Frame length (ms) 32.000000
Frames/second 31.250000
Num of frames 260077
Bytes per Frame 1536
Size % Framesize 0
CRC present: YES
=============================================

As can be seen comparing the number of 'extracted_audio_1.ac3' frames (260081) with the number of 'encoded_audio_1.ac3' frames (260077), it has actually cut 4 frames (=128ms). If you need further confirmation; I compared the input and output filesizes. There is a difference of 6144 bytes. This is equivalent to 4 frames (1536 bytes/frame).

So, to sum up, I required a delay of -80ms, and actually got a delay of -128ms. Can the author of besweet please confirm or check this?

Regards,
Bob

[Matthew]

Well, you are right, I just tried besweet b29 on a 448 kbps with delay -80 and it definately cut 4 frames at the beginning of the file.

As an aside, if this is a PAL DVD then there may not be a delay at all. -80 ms may be reported with some apps when the opening GOP has an atypical structure. This is wrong unless using a re-encoding method (e.g. plain vanilla DVD2AVI) that drops the first 2 frames (80ms). Donald Graft's modified version of DVD2AVI fixes this so there'd be more information in those threads if you are interested.

[bobwillis]

Hi Matthew,

Thanks for confirming it.

Yes, the -80ms delay did come from the older versions of dvd2avi due to 2 leading B frames.

This source was just used as an example to highlight that there may be something amiss with besweet. I recently bought a large 42" display, and was beginning to see lip sync problems with films where besweet was called using DVD2SVCD. I assume I am seeing them because on a larger display, people's mouths are bigger, so the viewer is more prone to noticing lip-sync issues. I then began watching things extremely closely several times over, comparing it to the original source (both displayed on my PC monitor), and there is definitely a lip-sync difference. People say that you should not be able to see/hear 40ms difference, but in the case where audio leads the video, I beg to differ. The human brain is accustomed to hearing the audio after seeing the visual event, on the account that light travels much faster than sound. Delays of upto +100ms are generally acceptable I find. However, if the audio leads the video, a much smaller discrepancy is tolerable.

The anomaly seems to exist with all sources and all specified delays. I just tried it with -287ms delay (differnt source), and it cut one more frame than expected.

Is there any tool for analysing this graphically, e.g. is it possible to see the original & delayed audio waveforms 'one above the other' in order see/measure the absolute delay? It occured to me that the delay may be correct and it could be the very last frame that is missing?

Regards,
Bob

[Matthew]

Nope it ain't the last frame that was missing, I was sure to check that when I did my test. I cut the first 4 frames off manually using ultraedit, then did a file compare, and the files matched.

The great thing about cutting AC3s is that it's just basic maths. Frames (assuming away any corruption) are always 32 ms and a frame in bytes is always (4 * bitrate).

So no need to fiddle with waveforms, a hex editor suffices :)

BTW once I did notice what I later discovered to be a 32 ms desync (one bad AC3 frame), but only at one or two specific points. Perhaps the audio/video was slightly out of sync to begin with and it was the straw that broke the camels back, so to speak.

[bobwillis]

Hi Matthew,

Thanks again for the further confirmation and useful info. I guess we'll wait for a fix from dspguru.

Incidentally, what do you think is the best way forward when non-integer delays are specified. My preference, is that the audio should always be kept behind the video.

For example, for -ve delays:
if a -1.5 frame delay is specified, then only cut by one frame.
if a -1.9 frame delay is specified, then still only cut by one frame.
if a -0.6 frame delay is specified, then do nothing.

for +ve delays:
if a 0.1 frame delay is specified, then delay by one frame.
if a 1.1 frame delay is specified, then delay by two frames.

This approach does not give the most numerically accurate solution, but it does prevent the audio from ever leading the video, which in my experience, people are far more sensitive to.

Regards,
Bob

[Matthew]

I'd never even considered the issue of desync being more noticeable when the audio leads the video. Of course, you are quite right to point out the difference.

As I traditionally do movie-only backups in Maestro, which allows specification of positive audio delays within 2 ms increments, it's never been a huge issue for me. Similarly when I use mplex+DVDAuthor, I can specify the exact delay with mplex.

If using Scenarist personally I'd just stick with the simple "whatever absolute delay is smallest" approach as it's simple. The worst desync is only 16ms then. I challenge anyone to notice that =)

[bobwillis]

Hi all,

Does anyone know if this issue was ever fixed in the later beta versions of besweet?

Regards,
Bob

[bobwillis]

Hi all,

Finally got round to doing a test today with a '-d -32' besweet command.
The file was an ac3 file with 32ms/frame. The -32 should have meant one frame was cut.
Unfortunately, the bug is still there, it cut two frames.

If anyone is in contact with besweet's author 'dspguru', can they please make him aware of this thread.

Thanks,
Bob

[KpeX]

Would you mind attempting this with besplit? (since splitting is it's intended purpose) Logfiles and delaycut output again would be helpful.

DSPguru is retired for all intensive purposes so besweet development is rather slow these days.

[bobwillis]

Hi,

Sadly, besplit does not have the same command line interface notation as besweet.

I'm looking for something that can be used within DVD2SVCD (for DVD2DVD ac3 purposes replacing besweet) which can accurately perform both -ve & +ve delay correction. At the moment, I manually use delaycut (outside DVD2SVCD) for accuracy reasons.

Regards,
Bob

[KpeX]

Hi,

Does besplit have the same command line interface notation as besweet? I'm looking for something that can be used within DVD2SVCD (for DVD2DVD ac3 purposes replacing besweet) which can accurately perform both -ve & +ve delay correction. Do you think besplit is a suitable replacement? At the moment, I manually use delaycut (outside DVD2SVCD) for accuracy reasons.

Regards,
BobUnfortunately the command line syntax is different enough between the two apps that I doubt it could be used inside D2S without significant changes to D2S. In this case I would recommend either manually using delaycut as you currently are, or just dealing with besweet's 1-frame error (since virtually no one will be able to detect a +/- 32ms skew).