Hi i love one radioshow so for a few years i record it each zaterday evening, because i want it to keep for the rest of my life in as good quality as i can get.

So far so good.

Each show is 2 hours so it costed 240..250mb but that way i could not fit many show on my mp3 player. So i decided a few weeks ago, it was time for some fine tuning / data tuning

When i started encoding in mp3 with Lame thats at least 5 years ago. I learned that96kps was good enough for analog radio. But that was not my experience (after some not blind testing) so i upped it each time until i feeled happy. My end settings were VBR minumum 32 and max 320kps Highest vbr quality and higest encoding quality (lame 398a8 and since last week 398b6 latest daily build).

Btw I record with totalrecorder pro, its easy, can edit and cut without re-encoding the mp3, does what it must without to many unneeded options and is not too expensive and has schedule functions. Totalrecorder can use external mp3 encoder like lame and supports most of its standard settings.

I analyzed my mp3 files with encspot and noticed all my frames were encoded at 192kps or higher not one frame was at 32 of 56kps, i wondered why but could not explain it and i started more testing.

At first i lowered the max from 320kps to 256, it helped to lower the avarage and the endfile was 190mb now without audible loss. But still no lowrate (32/56kps frames).

Then i tried something new. I shutdown the radio unchecked all lines in audio settings, volume up no no noice no sound and recorded. Now i should get some 56kps frames? No, i dont know what it recorded but i ended up with a file with 30kps lower avarage bitrate. Took a look with encSpot and still all the frames were 160/192kps. So i guess there is no use for lower rates in Lame when recording from analog radio, didnt try cd maybe it works there.

Then i recorded with the famous Q2 and Q4 settings i read about here, max 320 off course.

I am not an audiofile and maybe it was my imagination, but the Q4 setting gave me the idea that there was slissing the whole time so i forget about that one (140mb). Q2 was better 160..170mb but i had the feeling Q0 was still better and becuase of only 20mb extra, i didnt want to limit myself in audio, the profit in mb was to little in my opinion. ABX testing i read about but's more difficult with radio then cd/flac

My music type btw is like you could guess from my nickname:
SOUL like d-train, Earth Wind & Fire, Rick James, McFadden & Whitehead, Sharon red


So in the end i have a few conclusions/questions i hope yuu care to comment on those, so i could learn form you. If i am not clear enough just ask

1. Like i said i am imagining things in Q2 /Q0 or even Q4. On the other hand everybody looks only at cd/flac maybe Lame is not so good at encoding analog radio and are those settings not so usefull for radio.?

2. Why was every frame made with Lame in vbr 32..320 Q0 / best quality. => 190kps, were have the 32/56/96 frames gone, even when you record nothing (no source)?

3. What are your opinions about recording in only 96kps with analog radio?

4. What settings would you have choosen in Lame?

5. Would 48khz would have been be a better choice then the 44khz i normally use? The higher samplingrate would suggest so?

6. If recording with no source availeble already take 80% from the bitrate, hoe many % will be put to good use for the music, still 100% or does some bits get lost due noice?

You seem to have set the minimum to 192 kBit.


Radio is no different than other signals. If you think your radio recordings are not important and are allowed to have artifacts then go with low bitrate. But it is wrong to say that radio (with all the broadband noise) can be encoded transparent at low data rate.

I'd rather save space by recording mono than have artifacts in stereo 96 kBit/s. It will also produce noticeably less noise unless you have very expensive receiver and properly placed antenna.


You should record in the samplerate your audio gear runs at (most often 48000 Hz), optionally downsampling it later. Stereo FM radio has a strong sine wave at 19 kHz and a bit of other signal somewhere at 17 and 21 kHz. Trying to record the broadcast at 32 kHz may produce aliasing. 44.1k should be acceptable though.

EDIT: This applies to Europe. I don't know about U.S. FM Stereo.

US FM broadcast also places the pilot signal at 19 kHz, so I assume the rest of it is the same as well.

Thats the strange thing, my minimum is the lowest i can choose, 32kps and max is 320, only when i lower the max then the avarage lowers also.



Dont worry i only record at very very high quality. But i was referring to the hydrogen wiki page, that says 96kps is enough for analog radio.

But what i was thinking maybe there is some background white noice unhearable for my ear, but still present, eating up all the bits. When no radio signal present and still eating frames when the radiosignal is present. If it is a specific hz maybe i could filter it first and the record from the radio signal after filtering. Its a wil guess i know but i am trying to find out why no osund produces big files.

Will do some other tests later and hope to find the problem. is there some other program i can record with that uses commandline parameters? Then i could test that one too.

If your radio station is available as streaming audio data over the internet then you could capture it directly in that form and not have to reencode at all.

Try not to set any bitrate limitations, as LAME by itself won't go below 32 kbps or above 320 kbps. What happens if you don't give any parameters other than -V2 ?

Its total recorder so i can not a parameters only a few listbox choices. But read my next post it gets intresting :-)

After a few hours testing, i got some results.

I tried a few other conversion programs (recording in wave and later encoding to mp3) and got other results rather intresting. I saw more different frames, they were more spread out over.

After i while i got the idea that i found the problem. It must be some miscommunication between totalrecorder and lame, maybe becuase the lame settings have changed but TR not.
I was ready to write a letter, i had what i needed. and hoped for the best.

I tried to convert the 5 min wav with hand in a dos box.
E:\1 nog te branden>lame --preset fast standard t3.wav
LAME 3.98 (beta 6, Nov 5 2007) 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding t3.wav to t3.wav.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.3x) qval=0
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
11479/11479 (100%)| 0:24/ 0:24| 0:25/ 0:25| 12.017x| 0:00
32 [ 1] *
40 [ 0]
48 [ 0]
56 [ 0]
64 [ 0]
80 [ 0]
96 [ 21] *
112 [ 229] ****
128 [ 753] ***********
160 [ 4304] %%********************************************************
192 [ 5037] %%%%%%%%%%%%%%%%***************************************************
224 [ 861] %%%%%*******
256 [ 99] %*
320 [ 174] %**
-------------------------------------------------------------------------------
kbps LR MS % long switch short %
178.9 14.9 85.1 96.6 2.0 1.4
Writing LAME Tag...done
ReplayGain: -2.7dB

Proof enough i should say.


Then i noticed something else, joinst stereo, how could that be, becuase JS will only be used when Q>4, Q was 2 so i had to find the stereo switch.



Found it and tried again:
E:\1 nog te branden>lame --preset fast standard -m s t5.wav
LAME 3.98 (beta 6, Nov 5 2007) 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding t5.wav to t5.wav.mp3
Encoding as 44.1 kHz VBR(q=2) stereo MPEG-1 Layer III (ca. 7.3x) qval=0
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
11479/11479 (100%)| 0:22/ 0:22| 0:22/ 0:22| 13.582x| 0:00
32 [ 1] %
40 [ 0]
48 [ 0]
56 [ 0]
64 [ 0]
80 [ 0]
96 [ 0]
112 [ 0]
128 [ 0]
160 [ 1410] %%%%%%%%%%%%
192 [ 8472] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
224 [ 1290] %%%%%%%%%%%
256 [ 98] %
320 [ 208] %%
-------------------------------------------------------------------------------
kbps LR % long switch short %
194.5 100.0 97.0 1.8 1.2
Writing LAME Tag...done
ReplayGain: -2.7dB

This were i found the problem, in real stereo modem the frames were not spread out any more.

So it seems TR and Lame were communciation good. The problem lies in the combination high Q settings AND stereo mode. They eat bits for breakfast and lost of it.


Next i recorded a empty file in 16bit wave, 3 minutes long and encoded it 2 times.



The first shows:
E:\1 nog te branden>lame --preset fast standard noice.wav
LAME 3.98 (beta 6, Nov 5 2007) 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding Noice.wav to Noice.wav.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.3x) qval=0
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
6893/6893 (100%)| 0:14/ 0:14| 0:15/ 0:15| 12.339x| 0:00
32 [ 2] *
40 [ 0]
48 [ 0]
56 [ 0]
64 [ 0]
80 [ 0]
96 [ 0]
112 [ 4] *
128 [1992] %***************************
160 [4895] %%******************************************************************
192 [ 0]
224 [ 0]
256 [ 0]
320 [ 0]
-------------------------------------------------------------------------------
kbps LR MS % long %
150.7 2.1 97.9 100.0
Writing LAME Tag...done
ReplayGain: +51.0dB


And with real stereo:
even more bits.
E:\1 nog te branden>lame --preset fast standard -m s noice2.wav
LAME 3.98 (beta 6, Nov 5 2007) 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding Noice2.wav to Noice2.wav.mp3
Encoding as 44.1 kHz VBR(q=2) stereo MPEG-1 Layer III (ca. 7.3x) qval=0
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
6893/6893 (100%)| 0:11/ 0:11| 0:12/ 0:12| 15.305x| 0:00
32 [ 1] %
40 [ 0]
48 [ 1] %
56 [ 0]
64 [ 0]
80 [ 0]
96 [ 0]
112 [ 2] %
128 [1375] %%%%%%%%%%%%%%%%%
160 [5504] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
192 [ 10] %
224 [ 0]
256 [ 0]
320 [ 0]
-------------------------------------------------------------------------------
kbps LR % long %
153.6 100.0 100.0
Writing LAME Tag...done
ReplayGain: +51.0dB


So in the end it doesnt seem possible what i wanted in the first place. Low bitrates in frames with none or almost no music on high Q settings.
Even empty files seems to be encodes at 153kps even when there is nothing to convert to mp3. Here lies some work for the lame team i think, but maybe i am an idiot, i dont know it anymore. :-)

It seems that VBR is following a avarage bitrate line, so with High Q AND real stereo setting you get big files, and each file with the same length is almost as big as the file before it. And not like i thought, a frame per frame calculation on how many bit its needed for that frame.
That explains it all, maybe the lame team can find a way for that later.

For now i think i am done testing, there is nothing to win here, so i quit

If the noise is white, it covers the entire spectrum range by definition.


The term "radio quality" which surfaces in different programs bears little meaning. For example, Windows ACM calls 22050 Hz, 8-bit "Radio" – which is complete B.S. Maybe one could say that if a perfect quality source is reduced to the radio quality, it would have similar amount of information compared to a radio broadcast. But it will not sound like any type of real radio (I'm not talking about AAC and MP2 over HF/VHF).

Edit: I think everything seems clear from your logs. LAME needs more data to encode each channel separately (LR) than if selective MS stereo was used. Quoting what has been said many times, it makes no sense to disable MS stereo, no matter what is the signal.

wrong post

downmix to mono + 32khz and ~64kbps ... play with settings until you are satisfied with the results

Those files you encoded weren't really empty, they just sounded empty. Opening them in a sound editor and amplifying them should reveal some noise or junk. For the sake of completeness, here are two encodes to illustrate:

1. 1 minute of pure stereo silence, as created in Audacity:


2. 1 minute of pure stereo white noise, as created in Audacity, and reduced to roughly -85dB so the file sounded silent:


The files sound the same but are really very different, especially in the eyes of Lame.

I just wanted to correct a misconception on your part. Joint stereo IS real stereo, just an alternate way of representing it. Of the two ways of encoding stereo, sometimes one is more efficient and sometimes the other. All you have done is force the encoder to use the same encoding regardless of which is more efficient, and this can lead to larger files and/or poorer sound quality, depending on the material.


In FM broadcasting, the station is required to filter out anything above 15 kHz. Anything above this is necessarily noise. Since you are telling the lame to encode everything up to 19 kHz, you are specifying that 4 kHz of noise be encoded along with your audio data. The result is lots of wasted bits.

You need to add a low pass filter at about 16kHz. That's just --lowpass 16 in lame.

It'll remove all the near-ultrasonic junk, and bring the bitrate down considerably.

Cheers,
David.

gib : thanks for creating "noice" samples and testing them, that was the one thing i missed in the first place. I just wanted to check this out but i dont have to anymore. So i can use the time to test other things now.

pdg : after so many sites and people complaining about JS, that you lost important info. I was a long time afraid for JS and did everything in "real" stereo.
But after reading a lot of discussions here and a bit of testing here. From today on, I gone use JS. I see its the default value anyway when using lame (398b6) even with q0 and q2.

2Bdecided : i did a lot testing today also with different Q settings, with or without lowpas, etc. It didnt give me much profit when using Q2/JS, i went from 6594 to 6589 when using --preset fast standard (q2) lowpass 16.
Thats 5 whole kb profit :-)
But when Q0 / JS / LP16 is used there is indeed more profit 8595kb vs 7739kps, almost exactly the same kb result as when changing the max bitrate to 256 with the -B parameter.
Because i will continue to use the Q2 / 32..320 / vbr new / HQ setting, there is no need for lowpass anymore.


btw i noticed when using lowpass 15 it changes the 44khz inputfile to 32khz Dont know or thats a bug or normal behaviour.
See example. Also bitwise nothing change much from going 44khz to 33khz BUT frame wise, its like day and night. The frames spread out enormous this time, not only in the upper region but also in the lower. cant explain now how so much spreading is possible with only a khz conversion. Nothing else changed.

But looking at the figures, one could say this is how a good mp3 song should look. No conclusion here just thinking loud. trying to understand what happens here.

E:\>lame --preset fast standard --lowpass 16 org2.wav
LAME 3.98 (beta 6, Nov 5 2007) 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 15826 Hz - 16360 Hz
Encoding org2.wav to org2.wav.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.3x) qval=0
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
11486/11486 (100%)| 0:25/ 0:25| 0:26/ 0:26| 11.673x| 0:00
32 [ 0]
40 [ 0]
48 [ 0]
56 [ 0]
64 [ 0]
80 [ 1] *
96 [ 0]
112 [ 3] *
128 [ 60] *
160 [ 4359] %%%****************************************
192 [ 6896] %%%%%%%%%%%%*******************************************************
224 [ 139] %*
256 [ 14] %
320 [ 14] %

E:\>lame --preset fast standard --lowpass 15 org.wav
LAME 3.98 (beta 6, Nov 5 2007) 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), SSE (ASM used), SSE2
Resampling: input 44.1 kHz output 32 kHz
Using polyphase lowpass filter, transition band: 15097 Hz - 15484 Hz
Encoding org.wav to 33hkz.mp3
Encoding as 32 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.3x) qval=0
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
1035/1035 (100%)| 0:03/ 0:03| 0:03/ 0:03| 11.196x| 0:00
32 [ 0]
40 [ 0]
48 [ 0]
56 [ 1] %
64 [ 0]
80 [ 5] *
96 [ 56] ***********
112 [ 185] ************************************
128 [ 271] *****************************************************
160 [ 352] %*******************************************************************
192 [ 31] %*****
224 [ 58] ************
256 [ 39] %*******
320 [ 37] ********


Next on my list will be the differences between nspsytune and gpsycho model, because i noticed Lame seems to uses default nspsytune, while TotalRecorder Pro 6.1 (which calls exactly the same lame codec) uses gpsycho and has no overrule option.
And some more testing which is better 32khz, 44khz or 48khz. I use 44khz for now until one of the other two proves to a better choice. I guess 44khz is better tested because everybody uses it.

Funny you said that. It is availably but i never put effort in it. Somehow i thought it cant be good. But today i did some quick checking, i believe it was 128kps, but still i have the idea it sounds better then my analog radio. Need some more and better tests.

Talking about taking the hard way. but with streaming you could have a big problem if the stream stops or stutters, in two hours recording that can happen.
With analog fm recording you never have that problem.

But you said something about capture the stream without re-encoding, the last part sounds interesting. If i ever want to do that, which program you can recommend me? Google offers me 100's of programs and i dont want to install/test all 100's

Edit: found a few good rip tools, seems that the stream was not mp3but ASF (wma2/mp7) in 48khz / 140kps / cbr, but i also found out my Zen creative doenst want play asf audio files, so i have to convert them to mp3 anyway, which again introduces loss in quality. Damned someone up there wants to punish me for something i did wrong in the past.

If I remember right, the audio in a asf file is wma. Probably you can just extract the wma file from it without reencoding. I'm sure that someone that knows about this will chime in shortly.

Is this radio program available on more than one station? Perhaps you can find one that streams in a different format, perhaps even a higher quality.

Unless you have good directional antenna, it might happen that a person or a motorized vehicle goes by your receiver and creates a period of noise in the recording.

However, I'd rather record from radio if it's FM and I have good hardware. These streams are never intended for capturing and are therefore most often poor quality, because of low bitrate per channel and generally transcoded from the station's internal format.

ASF takes too much effort to convert and you'll never really know if that specific ASF will play in the future. I've captured and the stream would only play in ffmpeg, but not using Windows Media libraries. If there's a choice besides WMA – go for it.

Thanks for the tip, I found a program to do that ASFBIN, it extract the audio without recompression and is freeware. After extraction the 1889kb file was 1885kb but still called asf, so i renamed it in wma and put it on the Zen, it played
Then i tried the original captured ASF and renamed it to WMA without extraction/conversion. Gues what, that also played on the Zen.
It seems renaming the extension is all that is needed.

That was part one: now i have to test which of the two sounds better, they sound completly different, but i just cant tell which is the better file

j7n: thansk i will also take that in mind.

Just to let you all know how it ended. I did some testing and the analog radio recorded with lame 398b5 - q2 sounded much better then the webstream.
But i also noted that its not transparant always with q2, the song diamonds are a girl best friend from janet jackon. has a part with high sounding vocals and high sounding instrument that was the only part the the vocal lost its sharpness. It could have used some bits there. So my next recording will be in Q1 i think.

That's not the point. Everything above ~15.5kHz is noise. It cannot do any good, and can only (potentially) do harm. (This would be true even if you were using lossless). You may be lucky and find that the mp3 encoder ignores it anyway.

Unfortunately, if the mp3 encoder ever keeps any content above 16kHz, then either the quality stays the same and the bitrate goes up, or the bitrate stays the same and the quality goes down. I don't think you want either of these, so it's better to add --lowpass 16 when encoding from FM radio, even if it (sometimes) doesn't seem to make any difference.

Just my advice. Take it or leave it!

Cheers,
David.

Good point i never thought on that.

And if TR would support it, i would use it. But Totalrecorder uses a few listboxes for different MP3 choices.
I havent found a way to add a command line option to the other choices. No way to add --lowpas 16 yet.

But i have paid for TR, so i can ask their helpdesk or they will add such an option. Maybe am i lucky and they do it.

Thanks for pointing it out.

If you want more control over the recording and encoding process, I would recommend a little utility called LineInCode. It pipes recorded data directly to an encoder, eg. LAME, and can be found here:
http://liveincode.rm.pp.ru/ (scroll to the bottom)
The software at the top of the page is a GUI for it, but it's not as flexible.

If you wish to schedule recording using this utility, you can create a .bat file like this:


You can use the windows scheduler (in Control Panel) to choose when it starts recording, and the first line of the code controls how long it records for (in Hours:Minutes:Seconds, i've got it set to 1 and a half hours).

You can then use whatever LAME commandline arguments you like. And it's free

LineInCode : i shall have a look at it. sounds interesting.

Another option i was thinking about is try to edit the source, so that lowpass16 is a default value and then compile it myself. Dont know how difficult something like that is.

If you are using the LAME executable, you can define an environment variable "LAMEOPT=--lowpass 16", no need to modify the sources. But I would not do it globaly, but from the shell and start TR from there, so it gets the modified environment.

I looked in TR but it uses the lame_enc.dll.

Got some feedback fom Totalrecorder, i hoped they would add an inputbox for extra commands. But they said it isnt possible because lame_enc.dll doesnt have all the functionality as the lame.exe file.
so things like lowpass would work.

however they gave me a few suggestions
1. recording in lossless wav and compress it with command line tool afterwards.
2. the same but use the post processing option from TR, didnt see how i could do that becuase of the changing file name each recording.
3. compilling my own lame.exe were did i hear that before :-)


Not what i hoped but i give them credit for their support when you have a question. Always an answer even 5 years after buying and also a usefull one. try that MS :-)

There is a version of the dll that gets its parameters from an ini file. Someone should jump in here and supply the specifics. I believe it was written by john33.

Edit: Here is the page with the version I was refering to:
http://www.rarewares.org/mp3-lame-libraries.php

Here is my two cents... without going into too much detail, I've had much better luck recording radio to .wav using Audacity or Adobe Audition and encoding the file to MP3 in post. Obviously this takes a little more work and a lot more hard drive space... but even if you do it once, you'll be able to take that source file and encode it multiple ways until to you find the one that is optimal for your needs.