question about lame resampling

[iMaGe]

quote:
-----------------------------------------------------------------------
audio-bitrates below 128 (in lame) can cause sync-problems (and sound terrible), because lame is automatically downsampling to 32 or even 22kHz. i highly recommend to use 128 or 160 and nothing else. to avoid downsampling you have to add "--resample 48" to your lame commandline options if you encode at low bitrates.
-----------------------------------------------------------------------

i know that i should be using vorbis instead, but w/o any reliable splitting toolr for multi-cd rips.. i'm sticking w/ mp3s. above is a quote from gknot's help page. i've been ignoring this warning and been doing --alt-preset 80, and it resamples it to 32. i havent seen any sync issues, but i need to know what to look for. any previous posts on this? searching didn't really help.

[Manao]

There is two reliable splitting tools for ogm : nandub + vcut. take a look here : http://forum.doom9.org/showthread.php?s=&threadid=25951&highlight=vcut.

I've tried, it works perfectly.

Else, I already got sync issues with mp3 @ 80 Kbit/sec. With some movies, the audio was about 200 ms before or after the video, toward the end of the movie. I was able to reduce the problem with using nandub and the option 'change framerate so video and audio have same duration', but the result was still not perfect. That's one of the thing which made me choose ogg vorbis + ogm container.

[DJ Bobo]

I *never* got synch problems with *any* bitrate, EXCEPT where it changes from MPEG-1 Layer3 to something else like MPEG 2 or MPEG 2.5

Downsampling itself has *NO* impact on synch!

[Manao]

Are you sure ? So the sync problem came from the multiplexing of the mp3 vbr and the avi into one avi with nandub ?

[robUx4]

Originally posted by DJ Bobo
I *never* got synch problems with *any* bitrate, EXCEPT where it changes from MPEG-1 Layer3 to something else like MPEG 2 or MPEG 2.5

Downsampling itself has *NO* impact on synch!

Downsampling to lower than 32kHz changes the MPEG version (2 ot 2.5 depending on the sampling freq).

But for the whole file. So no sync pb should occur.

[Alestrix]

I even resample some of my audiotacks (normally the dubbed ones since I prefer the original soundtracks.) to 24kHz, using

--resample 24 --nspsytune --nssafejoint --lowpass 11 -b 64

or similar (sometimes higher bitrate, sometimes lower lowpass)
And never had any sync-problems.

Aside:
Unfortunatelly these tracks can not be muxed into the avi w/ nandub directly (nandub will mistake it for 48kHz) but they need to have a wav-header added (I use wavemp3.exe, don't remember where I got it from). Wavemp3 can only handle CBR, though, but some day I might look into low-bitrate, 24kHz VBRs created with BeSweet's 'WAV-MP3'-feature and whether NanDub can mux those WAV-VBR-MP3s propperly.

- A

EDIT:
higher bitrate (i.e. -b 80) is NOT possible using 24kHz, lame will mess up the mp3-header (128kpbs will be reported) and the length will be mistaken and render the mp3 useless for muxing.

[robUx4]

Originally posted by Alestrix
Aside:
Unfortunatelly these tracks can not be muxed into the avi w/ nandub directly (nandub will mistake it for 48kHz) but they need to have a wav-header added (I use wavemp3.exe, don't remember where I got it from). Wavemp3 can only handle CBR, though, but some day I might look into low-bitrate, 24kHz VBRs created with BeSweet's 'WAV-MP3'-feature and whether NanDub can mux those WAV-VBR-MP3s propperly.

You're very lucky. I published 2 days ago such an app to add a clean WAV header to MP3. It's working great with any type of MP3. (similar to what Nandub does, but "cleaner"/more regular).

I hope to finish tonight the version to handle MP2 and MP1 (nearly working but there's a bug with mono encodings).

see http://mukoli.free.fr/mpa2wav.v0.1.2.zip
and http://mukoli.free.fr/mpa2wav.v0.2.0.zip (buggy one, well for mono)

source included (GPL program)

[robUx4]

Updated code :

http://mukoli.free.fr/mpa2wav.v0.2.1.zip

It now works with MPEG I/II, Layer 1/2/3, CBR/VBR...
It also removes bad frames when found (no CRC check though).

[Alestrix]

Does that mean I can mux VBR using VirtualDub or even AviMux (-> more than 2 streams) now? Right now I only have oggs on my HDD, so I can't try it myself...

- A

[robUx4]

Originally posted by Alestrix
Does that mean I can mux VBR using VirtualDub or even AviMux (-> more than 2 streams) now? Right now I only have oggs on my HDD, so I can't try it myself...

- A

Yep, the same way. The result is the same as with Nandub (but cleaner AVI files).

The only problem I found is with drop frames in the original file.

[Alestrix]

Great Job!
I finally can mux my VBRs using VirtualDub :D (played a little bit with some random AVIs and MP3 I had floating around my HDD, so no sync tests done yet), but...

Originally posted by robUx4
The only problem I found is with drop frames in the original file.

I noticed that, too, but I'm sure you'll come up with a smart sollution :-)

PS: Unfortunatelly OggMux is not able to mux those wav-mp3s into an OggMedia (I thought maybe it could solve the mp3-in-an-ogm problem). Any thoughts on this?
PPS: Keep up the good werk!!!

- A

[robUx4]

Originally posted by Alestrix
I noticed that, too, but I'm sure you'll come up with a smart sollution :-)


Well, I haven't found a way, nor Avery Lee... It seems that the tricky Nandub way is still the best option (until good AVI replacement appears).
I just released a new version (http://mukoli.free.fr/mpa2wav/) that can keep also damaged frames in the final file. So if the MP3 file you have is damaged at the same point, you might not get sync problems (didn't test).

Originally posted by Alestrix
PS: Unfortunatelly OggMux is not able to mux those wav-mp3s into an OggMedia (I thought maybe it could solve the mp3-in-an-ogm problem). Any thoughts on this?
PPS: Keep up the good werk!!!


Since I never used OGG this way, I don't know at all.

[DSPguru]

Steve,
no offense, i'm sure you know i respect you and your work, but BeSplit already offers removal of wav header and bad audio frames for quite some time.


Cheers,
Dg.

[robUx4]

Originally posted by DSPguru
Steve,
no offense, i'm sure you know i respect you and your work, but BeSplit already offers removal of wav header and bad audio frames for quite some time.


In the case of mpa2wav it's not removable but addition...
Anyway I needed to program something like this, so... It's a code basis for mpa2mcf that I use.
(and I'm trying to make a context menu to make it easy for dumb people).

Also, I'm quite sure BeSplit doesn't put a FACT data chunk in the WAV header, which is mandatory, but noone uses (unfortunately, because it could help resolve sync problems).

[DSPguru]

no problems, steve, just wanted to let you know.

[ChristianHJW]

Originally posted by Alestrix I even resample some of my audiotracks (normally the dubbed ones since I prefer the original soundtracks.) to 24kHz

Hmmpfff .... lowpass at 10 - 11 KHz ?? This may sound like a 40 kbps WMA track ... i just hope i'll never get hold of any of your movies ... may damage/spoil my ears .. ;)

[robUx4]

Originally posted by ChristianHJW


Hmmpfff .... lowpass at 10 - 11 KHz ?? This may sound like a 40 kbps WMA track ... i just hope i'll never get hold of any of your movies ... may damage/spoil my ears .. ;)

Considering the video quality of a movie on 1 CD, it's not such a big problem. (having the best possible audio with crap video isn't worth). Also if you're movie is mostly spoken (with low music here and there) the difference won't be big.

[Alestrix]

Originally posted by ChristianHJW
Hmmpfff .... lowpass at 10 - 11 KHz??
Seems to me you never listened to a 10.5kHz tone? :-) Anyway, as a secondary audio stream (the dubbed one, as I said above) it's fine enough, since I normally only listen to the original soundtrack anyway...
But I still recommend you make a a listening test on your own, the difference is not that bad (as long you don't have great music and lot of car-crashes and stuff :-) )

- A

[ChristianHJW]

Originally posted by Alestrix the difference is not that bad (as long you don't have great music and lot of car-crashes and stuff :-)
Lame is not tuned for 24 Khz sampling rate .. so you dont win anything in terms of bitrate, you just compromise quality IMHO.

[Alestrix]

Originally posted by ChristianHJW
Lame is not tuned for 24 Khz sampling rate .. so you dont win anything in terms of bitrate, you just compromise quality IMHO.
I suggest you do the test yourself:

lame -b 64 --resample 44.1 --nspsytune --nssafejoint --lowpass 11 test.wav test44k1.mp3
lame -b 64 --resample 22 --nspsytune --nssafejoint --lowpass 11 test.wav test22k05.mp3

Well, it's not 48kHz vs 24kHz but most certanly comparable and the result leaves absolutely no room for personal bias, the 22k05 mp3 sounds WAY better than 44k1 at the same bandwidth.

I don't have any hard-to-encode samples on my HDD (yet) so I used track 3 from the remix album 'no protection' by Massive Attack vs Mad Professor ('trinity dub - three').

By the way: I think it would be a good idea to link to those problem samples in the Audio-FAQ (or some other appropriate place). I found the link once in one of the threads here and bookmarked it on my home-PC, but when I sat in the university today (where the bandwidth lives :-) ), there was absolutely NO FREAKIN' WAY to find those samples. No doom9-forum search, no google seach, do hydrogenaudio-forum seach revealed the URL to me...

Live fast and prosper
- A

[HarryM]

Resample function at Lame is

a) simple resampling of input signal???

or

b)resample sideeffect of freq-analyze at mp3 encoding proces (internal resampling)?

[Alestrix]

Originally posted by HarryM
Resample function at Lame is
a) simple resampling of input signal???
b)resample sideeffect of freq-analyze at mp3 encoding proces (internal resampling)?

I'm not a developer but from what lame tells you when encoding it seems resampling is done prior to encoding, like a preprocessor. I think it's probably kinda hard (if not impossible) to convert into Fourier space first and then reduce the number of input samples.

But a similar question for me: It seems to me (again, from the information lame prints out on encoding) as if the bandpass filters are also applied as a preprocessor, but wouldn't it save a lot of time to bandpass after FFT?

- A