Something wrong in BeSweet/BeLight.

[castellanos]

Hi there!
I'm having troubles (now) using this tools:
Converting from wave to any file (mp3, mp4, aac etc...) I get a clip at the begining of the file, and also, BeLight does not show anymore the status bar while transcoding:
http://img81.imageshack.us/img81/4232/foto13qg.jpg (http://imageshack.us)
It's possible to see in the picture that after 5 sec. transcoding there is nothing in the "Current Track" bar... also, does not show the "%" in the upper bar.

Here is the log just in case: (BeLight 0.22 beta9)

BeSweet v1.5b31 by DSPguru.
--------------------------
Using lame_enc.dll v1.32 (8/8/2003), Engine 3.90 <http://www.mp3dev.org/>.

Logging start : 05/27/06 , 13:45:16.

BeSweet.exe -core( -input D:\Work\Bach suite 4 - Courante.wav -output D:\Work\Bach suite 4 - Courante.mp3 -logfile D:\Work\Bach suite 4 - Courante.log ) -azid( -s stereo -L -3db ) -lame( -b 160 )

[00:00:00:000] +------- BeSweet -----
[00:00:00:000] | Input : D:\Work\Bach suite 4 - Courante.wav
[00:00:00:000] | Output: D:\Work\Bach suite 4 - Courante.mp3
[00:00:00:000] | Floating-Point Process: Yes
[00:00:00:000] | Source Sample-Rate: 44.1KHz
[00:00:00:000] +-------- LAME -------
[00:00:00:000] | Bitrate method : CBR
[00:00:00:000] | MP3 bitrate : 160
[00:00:00:000] | Channels Mode : Joint Stereo
[00:00:00:000] | Error Protection: No
[00:00:00:000] +---------------------
[00:03:10:006] Conversion Completed !
[00:03:10:006] Actual Avg. Bitrate : 160kbps
[00:00:12:000] <-- Transcoding Duration

Logging ends : 05/27/06 , 13:45:28.


This problem did not happen a week ago... and I didn't change anything.
Can somebody help me?
Greetings! :)

[castellanos]

Sorry guys... the question could be too specific or too stupid, but I really need help. It's really pitty that BeSweet/BeLight do not work as they used to (in my computer)... I love the tools.
Some ideas, please?
Greetings! ;)

[thuongshoo]

where do you have this wav file ? Is it made by Virtualdub ?
You try to convert this file with Behappy !

[castellanos]

Virtualdub??
No. Nothing to do with that. It's just a normal wave I've made at home (16bit, 44.1Khz, Stereo)...But the problem happen with any wave file.

[tebasuna51]

If the problem is only cosmetic (the mp3 works ok: "[00:03:10:006] Conversion Completed !") maybe you have a buggy version of BeLight. Try with a new/old one.

[castellanos]

Originally posted by tebasuna51:
Try with a new/old one.
I've already tried and the result is the same. I have "re-installed" BeSweet too and nothing.
I don't care about the cosmetics, but I get a clip at the beginnig of the file... and that's not very nice.

[tebasuna51]

A update to Lame 3.97b2 is also recommended.

Try also Lame.exe directly:

lame.exe -b 160 "D:\Work\Bach suite 4 - Courante.wav"

[castellanos]

I replaced the lame_enc.dll by the the new one and the result was the same. It does not happen with Nero/Lame, Or Lame alone.
Definetelly it's something wrong in BeSweet/BeLight and I don't know what!!! :(

[setarip_old]

If your OS is WinXP, try performing a "System Restore" back to the last time things were behaving properly...

[Kurtnoise]

Could you post a sample of your wav file somewhere ?

For status bar issue, i can't reproduce the problem here.

btw, I'm quite busy these days. I'll try to check this.

[castellanos]

Thank you very much Kurt for your interest, but the problem happen with any wav, not only that one... and to any format, no matter if the final is a mp3, mp4, aac... I get always the clip at the beginning of the track.
But here is the piece of wave anyway:

http://rapidshare.de/files/21755663/Bach_Test.wav.html

Greetings! :sly:

[castellanos]

I noticed that after a normal wav to mp3 convertion, the final mp3 is a little bit longer than the original wav... (may be the clip at the beginning?)

EDIT: Oh my!! :o I realized that the problem is only with a few wav files (as the posted above)... anyway, the wav/s are a normal PCM wav, 16bit, 44.1 Khz... I don't know where is the problem.

EDIT 2: Ok, I'm getting somewhere! I think BeSweet/BeLight have problems processing optimized audio file headers (Created - default - by WaveLab)

[tebasuna51]

I noticed that after a normal wav to mp3 convertion, the final mp3 is a little bit longer than the original wav... (may be the clip at the beginning?)
http://forum.doom9.org/showthread.php?t=111580
I realized that the problem is only with a few wav files (as the posted above)... anyway, the wav/s are a normal PCM wav, 16bit, 44.1 Khz... I don't know where is the problem.
Yes I only have this problem with your sample.
I think BeSweet/BeLight have problems processing optimized audio file headers (Created - default - by WaveLab)
What is "optimized audio file headers"?
WAVE_FORMAT_EXTENSIBLE headers?
BeSweet can't accept WAVE_FORMAT_EXTENSIBLE headers.

[castellanos]

Originally posted by tebasuna51:
What is "optimized audio file headers"?
WAVE_FORMAT_EXTENSIBLE headers?
I can't tell you, I did not find so much information about it.
When saving wave files (In WaveLab) one of the options are "Create optimized audio file headers"

Here (http://radio.hydrorecords.com/index.php?showtopic=728) they speak also about the problem, but is nothing said what actually "Optimized header" is.

EDIT: Create optimized audio file headers: "This option adds some space to align the first sample of the file on a disk sector. Note: Some applications do not properly read optimized Wave file headers. These applications read the space as the real start of the file, which can cause a click at the start. Disable the option if this occurs."

I think this solve the problem, right? :D
Greetings!

[tebasuna51]

I think this solve the problem, right?
Yes, this is the problem.
My wav analyzer accept this extra space and don't detect anything wrong, but open in WinHex I can see the problem. I delete, in WinHex, this extra space (and correct rifflength) and the resultant wav file is encoded by BeSweet without problems.

Then, only to document this bug (?) in BeSweet:

WaveLab, when make a wav with optimized audio file headers, create a correct (but not standard) subchunk 'PAD ', between subchunks 'fmt ' and 'data', padded with '0', to align the first real data at position 4096.

This subchunk 'PAD ', accepted by other audio soft (at least Lame.exe and Goldwave in my tests), is unrecognized by BeSweet, treated like real data and producing a initial click.

[castellanos]

Thanks for the explanation tebasuna51.
Indeed, Lame can process those files... unfortunatelly not BeSweet.
Saludos! :sly: