A cosmetical bug in besweet?

[SILICON]

Not is very important, but the time in the log [02:06:18:912]seems rare, isn't it?


BeSweet v1.5b25 by DSPguru.
--------------------------
Using azid.dll v1.9 (b922) by Midas (midas@egon.gyaloglo.hu).
Using Shibatch.dll v0.24 by Naoki Shibata & DSPguru (shibatch.sourceforge.net).
Using tooLame.dll v0.2l (Apr 24 2003) by Mike Cheng <http://tooLame.sf.net>
Manual Dynamic-Compression algorithm by LigH (author of WaveBooster).

Logging start : 01/02/04 , 02:33:08.

C:\DVD2CVCD\BESWEET\BESWEET.EXE -core( -input D:\jungladecristal\PELICULA.ac3 -output D:\jungladecristal\PELICULA.MP2 -logfilea D:\jungladecristal\DVD2CVCD.LOG ) -split( -start 30 -end 7609 ) -azid( -s surround2 -f1 ) -toolame( -m s -b 160 ) -ssrc( --rate 48000 ) -boost( /b2=5 ) -ota( -hybridgain -d -96 )

[00:00:00:000] +------- BeSweet -----
[00:00:00:000] | Input : D:\jungladecristal\PELICULA.ac3
[00:00:00:000] | Output: D:\jungladecristal\PELICULA.MP2
[00:00:00:000] | Floating-Point Process: No
[00:00:00:000] | PostGain normalize to : 0.97
[00:00:00:-96] +-------- AZID -------
[00:00:00:-96] | Input Channels Mode: 3/2, Bitrate: 384kbps
[00:00:00:-96] | Output Stereo mode: Dolby surround 2 compatible
[00:00:00:-96] | Total Gain: 7.000dB, Compression: None
[00:00:00:-96] | LFE levels: To LR -INF, To LFE 0.0dB
[00:00:00:-96] | Center mix level: BSI
[00:00:00:-96] | Surround mix level: BSI
[00:00:00:-96] | Dialog normalization: -4dB
[00:00:00:-96] | Rear channels filtering: Yes
[00:00:00:-96] | Source Sample-Rate: 48.0KHz
[00:00:00:-96] +-------- BOOST ------
[00:00:00:-96] | Algorithm by : Dg
[00:00:00:-96] | Boost Factor : 5.0
[00:00:00:-96] | Limit Factor : 0.73
[00:00:00:-96] +------ tooLame ------
[00:00:00:-96] | Bitrate method : CBR
[00:00:00:-96] | MP2 bitrate : 160
[00:00:00:-96] | Channels Mode : Stereo
[00:00:00:-96] | Error Protection: No
[00:00:00:-96] +---------------------
[02:06:18:912] Gain of -4.0dB had been asserted to file.
[02:06:18:912] Conversion Completed !
[02:06:18:912] Actual Avg. Bitrate : 160kbps
[00:15:04:000] <-- Transcoding Duration

Logging ends : 01/02/04 , 02:48:12.

[Tuning]

Originally posted by SILICON
Not is very important, but the time in the log [02:06:18:912]seems rare, isn't it?


Nothing rare in it, AFAIK. Its Hours: Minutes: Seconds: milliseconds.

Hope you got it...:)

[LigH]

It's obvously just a bit misunderstandung the meaning of the two times, and therefore a confusion why a previous time is bigger than a following:

[02:06:18:912] is the playback duration (last timestamp in the audio file);
[00:15:04:000] is the processing duration (how long it took to convert it).

[SILICON]

Originally posted by LigH
It's obvously just a bit misunderstandung the meaning of the two times, and therefore a confusion why a previous time is bigger than a following:

[02:06:18:912] is the playback duration (last timestamp in the audio file);
[00:15:04:000] is the processing duration (how long it took to convert it).

Ok. I´m very stupid :-)

Thanks for your help.