Besweet bug/annoyance: delaytime

[Npl]

Besweet doesnt allow long delaytimes, I tried to encode a ac3-file, cutting of some seconds of the start. To my surprise it actually added delay instead of removing.
Seems the skipped samples are computed by (delay*samplerate)/1000, causing an arithmetic overflow if delay is big enough (44740 in case of 48kHz). Getting that limit alot higher should be not much work - (delay/1000)*samplerate + ((delay%1000)*samplerate)/1000 would allow delays of ~12 hours.

Hope this can be changed in the next version as I often want to cut off some seconds to minutes.




BeSweet v1.5b31 by DSPguru.
--------------------------
Using azid.dll v1.9 (b922) by Midas (midas@egon.gyaloglo.hu).

Logging start : 11/24/05 , 22:49:17.

D:\Programme\BeLight\BeSweet.exe -core( -input D:\Dragonhero\VTS_01_PGC_01_1 - 0x81 - Audio - AC3 - 1ch - 48kHz - DRC - Deutsch - DELAY -80ms.ac3 -output D:\Dragonhero\deutschmono.wav -logfile D:\Dragonhero\deutschmono.log -noid3 -2ch ) -azid( -s stereo -c normal -L -3db ) -ota( -g 1 -d -47120 )

[00:00:00:000] +------- BeSweet -----
[00:00:00:000] | Input : D:\Dragonhero\VTS_01_PGC_01_1 - 0x81 - Audio - AC3 - 1ch - 48kHz - DRC - Deutsch - DELAY -80ms.ac3
[00:00:00:000] | Output: D:\Dragonhero\deutschmono.wav
[00:00:00:000] | Floating-Point Process: No
[00:00:-2:-380] +-------- AZID -------
[00:00:-2:-380] | Input Channels Mode: 1/0, Bitrate: 192kbps
[00:00:-2:-380] | Output Stereo mode: Stereo
[00:00:-2:-380] | Total Gain: 0.000dB, Compression: Normal
[00:00:-2:-380] | LFE levels: To LR -3.0dB, To LFE 0.0dB
[00:00:-2:-380] | Center mix level: BSI
[00:00:-2:-380] | Surround mix level: BSI
[00:00:-2:-380] | Dialog normalization: No
[00:00:-2:-380] | Rear channels filtering: No
[00:00:-2:-380] | Source Sample-Rate: 48.0KHz
[00:00:-2:-380] +---------------------
[01:32:49:620] Conversion Completed !
[01:32:49:620] Actual Avg. Bitrate : 6kbps
[00:01:50:000] <-- Transcoding Duration

Logging ends : 11/24/05 , 22:51:07.

[johnman]

An other option is to use floating points ofcourse ;).

(delay*samplerate)/(float)1000

[Npl]

An other option is to use floating points ofcourse ;).

(delay*samplerate)/(float)1000
Yup, using FP the overflows could also be reliable detected of course.
But make that (double) or your losing precision compared to my int32 code :devil:

[KpeX]

Since besweet updates are few and far between these days you may want to have a look at besplit ( or mplayer, or possibly DelayCut).