PDA

View Full Version : Problems decoding MP2 with BeSweet


akapuma
9th March 2004, 19:42
Hello,

this is my first thread in the english-speaking doom9-Forum, because my english is very terrible. Sorry.

My problem: If I want to decode MP2 (from DVB) with BeSweet, I get a short cracking at the beginning of the new file.

Here is my log-file:
BeSweet v1.5b25 by DSPguru.
--------------------------
Using hip.dll v1.19 by Myers Carpenter <myers@users.sf.net>
Using Shibatch.dll v0.24 by Naoki Shibata & DSPguru (shibatch.sourceforge.net).
Using Ogg Vorbis v1.0 dlls (http://www.vorbis.com).

Logging start : 03/07/04 , 19:36:30.

C:\PROGRAMME\GORDIANKNOT\BeSweet.exe -core( -input D:\Rekorder\xxx.mp2 -output D:\Rekorder\xxx.ogg -logfile D:\Rekorder\xxx.log ) -ota( -norm 0.95 ) -azid( -L -3dB -c heavy -s stereo -f1 -n1 ) -ssrc( --rate 44100 ) -ogg( -q 0.000 ) -profile( robot4rip v0.5.0.1090 )

[00:00:00:000] +------- BeSweet -----
[00:00:00:000] | Input : D:\Rekorder\xxx.mp2
[00:00:00:000] | Output: D:\Rekorder\xxx.ogg
[00:00:00:000] | Floating-Point Process: Yes
[00:00:00:000] | Overall Track Gain: 4.790dB
[00:00:00:000] +------ Shibatch -----
[00:00:00:000] | Source Sample-Rate: 48.0KHz
[00:00:00:000] | Dest. Sample-Rate: 44.1KHz
[00:00:00:000] | Attenuation : 0.0db
[00:00:00:000] +-------- OGG --------
[00:00:00:000] | VBR Quality : 0.000
[00:00:00:000] +---------------------
[00:00:20:656] Conversion Completed !
[00:00:20:656] Actual Avg. Bitrate : 66kbps
[00:00:06:000] <-- Transcoding Duration

Logging ends : 03/07/04 , 19:36:36.

And here is a graph of the file:
http://forum.gleitz.info/attachment.php?attachmentid=66262
Upper picture: Output with BeSweet (fault)
Lower picture: Output with HeadAC3he or ProjectX (OK)
The skaling of the two pictures isn't equal, so here are some timescodes:
BeSweet: Burst approx. 28ms, Beginning of the sound (first neg. peak): approx. 546ms
HeadAC3he/ProjectX: approx. 523ms

There are two problems:
1: the cracking at the beginning
2: the offset between both files, approx. 23ms. Bad for muxing video and audio.

First speculations, the input-mp2-file isn't correct, are not thrue. The mp2-file begins with a correct syncbyte. Discussions beyond this (in German), look here: http://forum.lucike.info/viewtopic.php?t=757

So, I think, the function of BeSweet isn't correct. Can anybody help me?

Thanks

akapuma

ps: Discussion in German without result (except "put it in the english forum")
http://forum.gleitz.info/showthread.php?t=11075

DSPguru
9th March 2004, 20:43
1. does it happen when you omit the resamping process ? (eg, without --rate 44100 )
2. i need a sample. say, first 1mb of that mp2.

akapuma
9th March 2004, 22:09
Hello DSPGuru,

thank you very much for your fast response and your great BeSweet!

After your reply, I tested all parameters. Originator of this problem wasn't --resamle, the originator was -ota( -norm 0.95 ):

The stringC:\PROGRAMME\GORDIANKNOT\BeSweet.exe -core( -input D:\Rekorder\Ton\xxx.mp2 -output D:\Rekorder\Ton\xxx01 .wav -logfile D:\Rekorder\Ton\xxx01 .log ) -ota( -norm 0.95 ) causes the problem, the string C:\PROGRAMME\GORDIANKNOT\BeSweet.exe -core( -input D:\Rekorder\Ton\xxx.mp2 -output D:\Rekorder\Ton\xxx.wav -logfile D:\Rekorder\Ton\xxx.log ) is OK.

In my first post, I used -azid. For explanation, the cause is, that I want to use the same parameters for ac3=>ogg and mp2=>ogg. But, this is irrelevant for this problem.

Here is the short sample: http://forum.gleitz.info/attachment.php?attachmentid=66282

Best regards

akapuma

akapuma
9th March 2004, 23:23
Hello,

I asked in the german lucike-forum, whether the beginning of the mp2-file is corrupt and told my problem:

http://forum.lucike.info/viewtopic.php?t=757

dvb.matt, author of ProjectX, wrote this:

Knackt es 'vorn', war IMO der dafür vorgesehene Buffer nicht resetted worden und enthielt 'alte' Daten. Ähnliches hatte ich schon bei einigen Dekodern selbst festgestellt.

Bad translation from me:
Is it cracking at the beginning, the designated Buffer wasn't resetted and contains old data. Similar, I detected this by some decoders myself

The parameter "-norm ,95" initiates the search of the maximum gain before the really transcoding starts (2 passes). Is it possible, that the first gain-finding-pass fills the buffer, which isn't resetted, before the transcoding starts?

akapuma

akapuma
12th March 2004, 20:51
Dear DSPGuru,

excuse please the demand, but I've two questions:

1: Is the problem comprehensible?
2: Is the problem fixable?

friendly greetings

akapuma

DSPguru
12th March 2004, 22:21
everything in this subject is fixable (unlike mathematical challanges i'm upto, lately), but i just don't have the time to check it out.
there's indeed a possibilty that the click at start is due to a prefilled buffer from the first pass, and perhaps got something to do with shibatch, as well. i'm not ignoring your message, but can't promise a quick troubleshot, on the other hand.

anyhow, my consistent suggestion for more than a year now, is to use Hybridgain as a normalization method. this should avoid your bug.


Cheers,
Dg.

akapuma
13th March 2004, 12:52
Hello,

Originally posted by DSPguru
and perhaps got something to do with shibatch
it's independent from shibatch, look in my post from 9th March 2004 22:09 in this thread. The parameters are completely indicated.

Originally posted by DSPguru
anyhow, my consistent suggestion for more than a year now, is to use Hybridgain as a normalization method. this should avoid your bug.

Yes, this avoids my bug, but I love pregain, because the Postgain is set to 0dB.

Greetings

akapuma

akapuma
11th May 2004, 23:38
Hello,

I testet it with the new BeSweet v1.5b27, but the problem isn't unfortunately fixed. But I made a new picture.

Upper picture with pregain (-ota( -norm 0.97 )):
- cracking at the beginning
- offset, approx. 30ms. Bad for muxing audio and video in a movie
- maximum use of dynamic range
- postgain=1,000, determined with CoreVorbis Audio Decoder

Lower picture with hybridgain:
- no cracking at the beginning
- no audio offset
- no maximum use of dynamic range, that's poor
- postgain=1,772, determined with CoreVorbis Audio Decoder

Ask, dear DSPguru, can you fix my Problem? MP2 is the standard of DVB audio, but not the optimum to process it in an ogm or mkv-file.

Best regards

akapuma

Picture (http://board.gulli.com/attachment.php?postid=1917242)

edit: offset isn't 0,3ms, it's 30ms

DSPguru
12th May 2004, 00:17
i can't enter the link you gave me, and therefore, understand almost nothing from your post.
how about logfiles and the starting 1mb of your source input file ?

akapuma
12th May 2004, 21:13
Hello DSPGuru,

sorry for the broken link. The Picture and the log's are here:
http://forum.gleitz.info/showpost.php?p=97727&postcount=16

The mp2-File is here, it's only a short test-file, the same as at last.
http://forum.gleitz.info/attachment.php?attachmentid=66282

I extended my tests:

BeSweet 1.5b28 instead of b27: same result
Same command line without -ssrc: same result, ssrc isn't the reason

Please, look in my post from 9th March 2004 23:23 in this thread. Isnt't this the solution of my Problem?

Best regards

akapuma

DSPguru
12th May 2004, 22:28
the pregain mp2-bug had been shooted in latest build (http://dspguru.notrace.dk/beta.html).

if i understood correctly your picture, the hybridgain indeed didn't create this click at start.
now, may i ask how did you decode the ogg stream to conclude there's no full use of dynamic range ?
according to logfiles :
1. pregain : Overall Track Gain: 4.971dB
2. hybridgain : Gain of 5.0dB had been asserted to file

so i suspect that your decoder ignored the postgain tag.
winamp/foobar/oggds/corevorbis does not ignore it.

akapuma
13th May 2004, 00:03
Hello,

the audio-files for my picture are created with build b28. The log-files and the picture belongs together. You can see, that the files are created with build 28.

You understood correctly, the hybridgain indeed didn't create this click at start.

I opened both files with the program audacity.
The amplitude of the file created with pregain is considerably higher than the amplitude auf the file created with hybridgain.

I played both files with a player, using the CoreVorbis audio decoder. The CoreVorbis audio decoder shows me the postgain-value.
The postgain-value for the pregain-file is 1.000 (absolute, no dB)
The postgain-value for the hybridgain-file is 1.772 (absolute, no dB)

My calculation for a normalized file with Volume=100%
Volume = Range x PostgainValue
pregain: Volume = (100% of Range) x 1.000
hybridgain: Volume = ( 56% of Range) x 1.772

Yes, I think, that audacity ignores the postgain-tag in it's graph. But, I think, if the postgain-tag is set to 1.772, the maximum range in the file in only used for 56%.

If I play both files, the volume is OK, because the CoreVorbis audio decoder analyses the postgain tag.

Thats the reason, why I like pregain. But, there is the click at start and the offset.

Best regards

akapuma

DSPguru
13th May 2004, 00:19
you indeed tested v1.5b28, but as hinted before, you should retry with the latest build.. ;)

note: 0.56*1.772=0.9923

akapuma
13th May 2004, 12:19
Hello DSPGuru,

thank you very much! The newest build works with mp2 and pregain:

- maximum volume
- no click at the beginning
- no offset

Best regards

akapuma