[BeSweet 1.5b27 bug]: Freezes at the end of large ac3 file

[arno]

I'm currently investigating a problem related to VBR encoding in Gordian Knot. While doing this I ran into another problem while encoding my Titanic DVD (which is a little of 3 hours in size). Both (at least) BeSweet b26 and b27 hang at (or near) the end of the file.

This is my log:

BeSweet v1.5b27 by DSPguru.
--------------------------
Using azid.dll v1.9 (b922) by Midas (midas@egon.gyaloglo.hu).
Using lame_enc.dll v1.32 (8/8/2003), Engine 3.90 <http://www.mp3dev.org/>.

Logging start : 05/09/04 , 22:31:29.

E:\PROGRA~1\GORDIA~1\BeSweet.exe -core( -input H:\MultiMedia\titanic\titanic AC3 T01 3_2ch 384Kbps DELAY 0ms.ac3 -output H:\MultiMedia\titanic\titanic AC3 T01 3_2ch 384Kbps DELAY 0ms_2.mp3 -logfile H:\MultiMedia\titanic\titanic AC3 T01 3_2ch 384Kbps DELAY 0ms_2.log ) -ota( -hybridgain ) -azid( -c normal ) -lame( -h --abr 128 ) -profile( Gordian Knot 0.28 )

[00:00:00:000] +------- BeSweet -----
[00:00:00:000] | Input : H:\MultiMedia\titanic\titanic AC3 T01 3_2ch 384Kbps DELAY 0ms.ac3
[00:00:00:000] | Output: H:\MultiMedia\titanic\titanic AC3 T01 3_2ch 384Kbps DELAY 0ms_2.mp3
[00:00:00:000] | Floating-Point Process: Yes
[00:00:00:000] | PostGain normalize to : 0.97
[00:00:00:000] +-------- AZID -------
[00:00:00:000] | Input Channels Mode: 3/2, Bitrate: 384kbps
[00:00:00:000] | Output Stereo mode: Dolby surround compatible
[00:00:00:000] | Total Gain: 10.000dB, Compression: Normal
[00:00:00:000] | LFE levels: To LR -INF, To LFE 0.0dB
[00:00:00:000] | Center mix level: BSI
[00:00:00:000] | Surround mix level: BSI
[00:00:00:000] | Dialog normalization: -4dB
[00:00:00:000] | Rear channels filtering: No
[00:00:00:000] | Source Sample-Rate: 48.0KHz
[00:00:00:000] +-------- LAME -------
[00:00:00:000] | Bitrate method : ABR
[00:00:00:000] | Avarege Bitrate : 128
[00:00:00:000] | MP3 Min bitrate : 32
[00:00:00:000] | MP3 Max bitrate : 320
[00:00:00:000] | Channels Mode : Joint Stereo
[00:00:00:000] | Error Protection: No
[00:00:00:000] +---------------------


Windows says Besweet is still running (so it hasn't crashed) but it just hangs like this (with the cursor still blinking):


[03:07:22:272] transcoding ...


I can terminate it but it seems that the final file lacks a correct VBR header (I understood that the VBR header bug should have been solved by now from Lenox (Gordian Knot developer). Any clues on what could be the problem. If you like a can put the file showing the problem on my ftp, although it's about 539mb in size (maybe I can cut off something by packing it, but I guess not much).

[DSPguru]

hmm... don't know what to say.
i just encoded a larger ac3 file (630mb), and everything went ok.
the resulted mp3 is 172mb, a postgain of 3db had been applied, the vbrtag had been updated and i'm currently playbacking the file without problems..

let me suggest the following commandline to help us find the source of the problem. please post its logfile :
-core( -input H:\MultiMedia\titanic\titanic AC3 T01 3_2ch 384Kbps DELAY 0ms.ac3 -output H:\MultiMedia\titanic\titanic AC3 T01 3_2ch 384Kbps DELAY 0ms_2.mp3 -logfile H:\MultiMedia\titanic\titanic AC3 T01 3_2ch 384Kbps DELAY 0ms_2.log ) -azid( -c normal --maximize )

[arno]

Originally posted by DSPguru
hmm... don't know what to say.
i just encoded a larger ac3 file (630mb), and everything went ok.
the resulted mp3 is 172mb, a postgain of 3db had been applied, the vbrtag had been updated and i'm currently playbacking the file without problems..

let me suggest the following commandline to help us find the source of the problem. please post its logfile :
-core( -input H:\MultiMedia\titanic\titanic AC3 T01 3_2ch 384Kbps DELAY 0ms.ac3 -output H:\MultiMedia\titanic\titanic AC3 T01 3_2ch 384Kbps DELAY 0ms_2.mp3 -logfile H:\MultiMedia\titanic\titanic AC3 T01 3_2ch 384Kbps DELAY 0ms_2.log ) -azid( -c normal --maximize )

First of all, I have to correct something. The previously noted MP3 file DID have an VBR header.

I did what you said and this is the resulting log file:

BeSweet v1.5b27 by DSPguru.
--------------------------
Using azid.dll v1.9 (b922) by Midas (midas@egon.gyaloglo.hu).
Using lame_enc.dll v1.32 (8/8/2003), Engine 3.90 <http://www.mp3dev.org/>.

Logging start : 05/10/04 , 14:47:49.

e:\Program Files\GordianKnot\BeSweet.exe -core( -input H:\MultiMedia\titanic\titanic AC3 T01 3_2ch 384Kbps DELAY 0ms.ac3 -output H:\MultiMedia\titanic\titanic AC3 T01 3_2ch 384Kbps DELAY 0ms_2.mp3 -logfile H:\MultiMedia\titanic\titanic AC3 T01 3_2ch 384Kbps DELAY 0ms_2.log ) -azid( -c normal --maximize )

[00:00:00:000] +------- BeSweet -----
[00:00:00:000] | Input : H:\MultiMedia\titanic\titanic AC3 T01 3_2ch 384Kbps DELAY 0ms.ac3
[00:00:00:000] | Output: H:\MultiMedia\titanic\titanic AC3 T01 3_2ch 384Kbps DELAY 0ms_2.mp3
[00:00:00:000] | Floating-Point Process: Yes


And again it's hanging at the end of the file with this screen:

[03:07:21:504] | Maximum Gain Found : 10.5dB


What else can I do as it seems this doesn't give much info.

[DSPguru]

try fixing the ac3 file with BeSplit/BeSliced.

[arno]

Originally posted by DSPguru
try fixing the ac3 file with BeSplit/BeSliced.

Ok.

I had another look at the VBR issue. But I did find something. It seems that BeSweet, when it creates an MP3-VBR output-file, does NOT create a LAME tag (containing a Xing-header), this causes problems with some programs (like Gordian Knot), that detects whether an MP3 file is CBR or VBR, by looking for the "Xing" header (inside the LAME tag). Can this be fixed in BeSweet (for the sake of compatibility with apps like this?)?

[DSPguru]

Originally posted by arno
It seems that BeSweet, when it creates an MP3-VBR output-file, does NOT create a LAME tag (containing a Xing-header)you're wrong.
i don't know what drove you into this conclusion (you didn't mention what kind of encoding you were doing, you didn't post a logfile), but this surely is a generalized rashed one.


btw,
any reason why you're using "--abr" instead of "--alt-preset" ?

[arno]

Originally posted by DSPguru
you're wrong.
i don't know what drove you into this conclusion (you didn't mention what kind of encoding you were doing, you didn't post a logfile), but this surely is a generalized rashed one.


btw,
any reason why you're using "--abr" instead of "--alt-preset" ?

Because this is also the default used by Gordian Knot.

Anyway, it seems (you're right, I'm sorry) that a Xing header is written, but that it's written after BeSweet finishes encoding (which wasn't the case with my previous (freeze) sample). So sorry for bothering you about this then.

Only thing I'm still wondering about is what's causing the freeze with this particular sample. Is this just corruption in the AC3-source? And isn't there anyway for BeSweet to avoid hanging on such a clip?

[DSPguru]

Originally posted by DSPguru
try fixing the ac3 file with BeSplit/BeSliced.