Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: 192 kbps (Read 10587 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

192 kbps

for some reason,I want to use 192 kbps cbr & normal stereo
only.
I guess I'm too lazy to find it out myself,so if anyone
would be kind enough to provide me with the best setting
that accommodates my need above?
perhaps
--alt-preset cbr 192 -ms
would do the trick? (quick guess)

also,can u tell me the full command line
of --alt-preset cbr 192 ?
(please,don't tell me to look into parse.c , I'm lazy, as I stated above  .At least somebody message me with it (Dibrom??)

192 kbps

Reply #1 –
Hmmm... I'm not 100% sure about this, but I think the alt-presets consist of more than just command-line switches (ie. changes in the actual LAME code).

I also think that all the alt-presets are optimised for joint-stereo only, since that is what really gives best quality if properly used.

For more info on why you should stick with joint-stereo, see this thread:
http://66.96.216.160/cgi-bin/YaBB.pl?board...2963624&start=3

But if you really want to stick with a stereo 192 kbps CBR, I'd suggest a command-line similar to this:

-b 192 -ms -h --nspsytune --athtype 2 --lowpass 19 --scale 0.98

(This line probably has room for some more tweaks, but I guess it's a good start...)

EDIT: Updated the 192 CBR command-line a bit.

192 kbps

Reply #2 –
Quote
Originally posted by el00343
for some reason,I want to use 192 kbps cbr & normal stereo
only.


Hrmm.. lemme guess  It wouldn't happen to be because that's what the ripping "scene" says you should, would it?

Quote
--alt-preset cbr 192 -ms


The alt-preset part should.. but with MP3, you really shouldn't be using stereo over joint stereo, especially at those bitrates IMO.  That is, unless you can actually ABX the difference between stereo and joint stereo in that situation, and if you can, I'd like to know about it (to improve things).

Quote
also,can u tell me the full command line
of --alt-preset cbr 192 ? 
(please,don't tell me to look into parse.c , I'm lazy, as I stated above  .At least somebody message me with it (Dibrom??)


Hehe.. I'd have to look in parse.c myself  (and I'm kinda busy at the moment).  I don't remember every detail off the top of my head for the cbr/abr stuff since it's just easier to remember the "--alt-preset" part unless I am tuning stuff.

Look in parse.c and search for "abr_switch_map" without the quotes.

192 kbps

Reply #3 –
Quote
Originally posted by Dibrom
Hrmm.. lemme guess  It wouldn't happen to be because that's what the ripping "scene" says you should, would it?


yep...you caught me here,dibrom!

Anyway, thanx for the info...I'm going to check this parse.c file
now

192 kbps

Reply #4 –
You can also get a lot of info about the used settings wit the '--verbose' switch.

192 kbps

Reply #5 –
Quote
Originally posted by Speek
You can also get a lot of info about the used settings wit the '--verbose' switch.


Yes, but --verbose is also useless with all of the --alt-preset VBR (and eventually ABR/CBR when I synch them up with the VBR stuff) modes, since a lot of the things which --verbose lists, actually change frame by frame with --alt-preset and the --verbose switch will only list values for the very first frame encoded.  Eventually I'll have to update the output to where it will show things changing on the fly (like the histogram does for bitrate and stuff) and probably show an "average" at the end of the file for each setting used (different X modes for example).  I probably won't do this for awhile though since it's not particularly pressing.

192 kbps

Reply #6 –
He raises a valuable point here.  I have many of my albums encoded with the Radium FhG codec, and I wanted to re-encode my stuff because of the advances in LAME since I did it.....It does have better quality than FhG now, doesn't it?  Anyway, should I do this, I don't want to have a bitrate above 192...Unlike him, I don't need CBR, but I do want an average bitrate below or equal to 192 with superior quality to the Radium codec.  I tried the --alt-preset standard and found that for the most part the bitrates are around 200 -  230...Thats too high.  I'm not tryin to bash your work or anything, Dibrom...thats not my intention here....But you need a preset that uses the full capability of LAME at a lower bitrate.  Its just too much.  Let me know what you think....I know about the ABR presets, but I'm lookin more towards the VBR aspect.

192 kbps

Reply #7 –
I've just ripped and compressed about a dozen of my CDs. A mix of pop and jazz.

On AVERAGE, it is close to 192Kbps. As I was watching the LAME histrogram during the compression, I've observed that the distribution of frame sizes varies from record to record, and it is hard to say what would be the final result. On some CDs, at least 60-70% of the frames are equally distributed between 160 and 192, on same majority is 192, or some it is equally distributed between 192 and 224 (I think 224 is correct size?) So the mileage varies from CD to CD. Do I really care? Not a bit, because the quality remains consistent from CD to CD and this is what I really care about. And the quality is nothing short of outstanding. I'm compressing directly on my laptop's hard drive and listening through good quality cans. My friend who owns the MAC and did some compression at 192Kbps with whatever Itunes come with,  had a chance to listen and compare and told me that was a first time he had such a good sound from mp3 played back on PC.

192 kbps

Reply #8 –
Quote
Originally posted by bighouse
He raises a valuable point here.


I don't think the thing he is talking about is specifically related to bitrate so much as the "scene" rules.  At least, I didn't see him mention anything about bitrates being too high with vbr.

Quote
I have many of my albums encoded with the Radium FhG codec, and I wanted to re-encode my stuff because of the advances in LAME since I did it.....It does have better quality than FhG now, doesn't it?


Yes, at least in VBR, and it has for some time really.

Quote
Anyway, should I do this, I don't want to have a bitrate above 192...Unlike him, I don't need CBR, but I do want an average bitrate below or equal to 192 with superior quality to the Radium codec.  I tried the --alt-preset standard and found that for the most part the bitrates are around 200 -  230...Thats too high.


What kind of music do you listen to?  One thing you have to keep in mind here is that there is obviously going to be some music that encodes at a higher bitrate than others.  Metal (I'm talking very heavily distorted stuff, blackmetal, death metal, etc.. not just rock or normal heavy metal) for example, will often encode towards to 200-230kbps range.  However, classical, electronic, and other genres should often encode lower than 192kbps.  Averaging out across a wide range of genres and albums, --alt-preset should come extremely close to 192kbps in bitrate.  As for why some genres end up encoding with more bits than others, the problem lies with LAME's implementation of true VBR and some of the weaknesses the MP3 format suffers which cause certain signals (which some genres have a lot of) to be more "expensive" than others.  There is no way for me to hit a bitrate of 192kbps or below, every time, without ABR or 2 pass VBR.  If I lower the top end bitrate range of --alt-preset to be in line with 192kbps, than other genres of music will encode in the 128-160kbps range and will not be high enough quality.

I am curious though, what kind of music and how many albums you encoded to come to the conclusion that the bitrate is always in the range you specified, because this is not the case on a more wide scale.

Quote
I'm not tryin to bash your work or anything, Dibrom...thats not my intention here....But you need a preset that uses the full capability of LAME at a lower bitrate.


If it was easily possible for to acheive what I (and others) feel to be "reasonable" quality at lower bitrates, believe me I would do it

Quote
Let me know what you think....I know about the ABR presets, but I'm lookin more towards the VBR aspect.


Hrmm.  Well, despite the fact that ABR may not really be what you are after, I think that might be the best bet right now if you really have to hit 192kbps.  For bitrates lower than what --alt-preset standard provides, I'm not so sure VBR is the way to go.  The possibility of introducing artifacts and things like that on quiet music starts to become a very big problem, and is the main issue I faced during my testing of --alt-preset normal... which was intended to be something similar to what you are speaking of.  In the end I had to just scrap the preset because I felt that the problems were too hard to overcome while still keeping the bitrate within the range I was shooting for.

Not even the --r3mix switch which may average slightly lower than 192kbps (and which I regard as being too low in quality and having too high of an ATH) encodes music like Metal with bitrates below 192kbps.  In fact, --alt-preset standard is often lower in bitrate on this music than that preset even.

At any rate, I think that in the end, if you need lower bitrates and quality as high as it is with --alt-preset standard... you'd probably be better off looking at a more efficient format.  Something like MPC -standard or perhaps one of the Vorbis VBR modes should do the trick.

192 kbps

Reply #9 –
"the scene" is poisoned by the misinformation spread by alt.binaries.sounds.mp3.d and their FAQ that hasn't been updated since 1923.

Take for instance:
Quote
[3.11] Enough tap dancing around the answer, just tell me WHAT ENCODER IS THE BEST? 

Okay, okay, you've come to the FAQ for an answer, so here is an answer.  In no particular order, the encoders of choice are Blade, an older version of the Fraunhofer codec L3enc version 2.0 (capable of true-stereo encodes) and the newer versions of Fraunhofer IIS MPEG Layer-3 Encoder (v3.1 - external CODEC mp3enc31 and v1.263 - internal CODEC - look for these in alt.binaries.sounds.utilities).  Beginning October, 1999, MusicMatch Jukebox began using a Fraunhofer CODEC which can produce a good encode if set for high quality (slower).  Start with these, give others a try, and let your own ears be the judge.


You can read more of this little gem at:
http://www.mp3-faq.org/

So make sure you keep everything encoded with the latest release of Blade at 192 stereo (oooh the purity!!)  to prevent that horrible "flanging" presented by the evil joint-stereo. :eek:
You can't kill the Elephant.

192 kbps

Reply #10 –
Quote
Originally posted by wildboar
"the scene" is poisoned by the misinformation spread by alt.binaries.sounds.mp3.d and their FAQ that hasn't been updated since 1923.

Take for instance: 
 
[...]


LOL!.... man.. it's too bad stuff like this is still posted and that people actually believe it.  Blade, and L3enc = "High Quality".  Hahaha...

192 kbps

Reply #11 –
I'm not laughing... I think as sad..hence have to convince my own friends to use lame an not some 5 years old FHG ACM codec :-(

people are even using X'ing and i cannot convince them to use lame...sad sad sad...people are forgetting how quick the world of Computers are moving
Sven Bent - Denmark

192 kbps

Reply #12 –
well,some people REALLY want to stick to 192 kbps cbr,
so I'm not the one to tell them 'NO'.
Even if u tell them how better is this or that,they will tell you 'no'
because simply this bitrate offers transparent quality for
them and they trust it.

I myself use --alt-preset fast standard
(previously an r3mix user)

192 kbps

Reply #13 –
[A bit of an inside joke but you will get it: For highest appreciation you should have been following the Prince's "manifestoes" and read the lyrics for hist latest release "The Rainbow Children"]

Hallelujah! In this time of Christmess and misinformation you need to spread the word to the children. Show them the OGG. Go forth and tell them of the blessing that be in the OGG. The open source will be kept We will fly high on the wings of the new code. No more licenses. The reverse of MP3 is 3PM! It's late.

Open their eyes with ABR, VBR, ABX and STD!
Tell them of the great rotating Xiph that comes in the night!

Open their mind for the flexible encoding. Update their beliefs. Show them the true way!!!! (yay, only 4 exclamation marks)
Kick their pants. Make them give a duck. Tell us the code, brother! Preach the parameters!

Hallelujah!!!!

192 kbps

Reply #14 –
This guy's gonna start a religion soon...

192 kbps

Reply #16 –
Quote
Originally posted by rjamorim
This guy's gonna start a religion soon...


Say it out loud: "I'm an Ogger, and I'm proud"!

And now for the singalong:

"I want my RC3.....

Look at them coders, that's the way you do do it..
they're doing the tweak on the RC3
That ain't patents, that's the way you do it
stay up late and do your code for free.."
That ain't debugging, that's the way they write it
Let me tell you, that source ain't dumb
Erm...
Nananananananana-nananana
Nananananananana-na

We got to install Microsoft OS'es
Fraunhofer and strange keys
We got to watch these blue screens
We got to hack our own registry..."
...
...
...

May the Xiph be with you.

Right on!

192 kbps

Reply #17 –
Quote
Originally posted by YinYang

"I want my RC3.....

Look at them coders, that's the way you do do it..

ROTFL :rofl:

(I know, I've nothing to say, but I love this song)
--
Ge Someone
In theory, there is no difference between theory and practice. In practice there is.

192 kbps

Reply #18 –
Quote
Originally posted by Benjamin Lebsanft
Oggism



orgasm
Sven Bent - Denmark

192 kbps

Reply #19 –
Hi everyone. Very funny, those last few posts! I've read this entire thread, and would like (if possible) to at least temporarily bring it back into focus: I too would prefer (again, if possible) to encode the majority of my music at 192kbps CBR.

  However, unlike many others making this choice, I was NOT swayed by "what the ripping 'scene' says you should [use]." The only *.mp3's I trade or receive from others are Old Time Radio programs, nearly all of which were encoded at 32kbps/22kHz. In rare instances I also download audio from MP3.com (such as the excellent collection of routinely updated music in Roger McGuinn's FolkDen, which is linked from http://mp3.com/mcguinn), but those are all standardized at 128kbps. In short, I don't really know or care what the ripping "scene" prefers.

  So why would I settle upon 192kbps CBR? Well, the main advantage the MP3 format offers is portability. Here is a rough guide showing what an 80-minute/70 Mb CD-R should hold, at various bitrates:

    320kbps CBR = 5 hours, 6 minutes
    288kbps CBR = 5 hours, 40 minutes
    256kbps CBR = 6 hours, 22 minutes
    224kbps CBR = 7 hours, 17 minutes
    192kbps CBR = 8 hours, 30 minutes
    160kbps CBR = 10 hours, 12 minutes
    128kbps CBR = 12 hours, 45 minutes
    112kbps CBR = 14 hours, 34 minutes
    096kbps CBR = 17 hours
    080kbps CBR = 20 hours, 24 minutes

  Now, a few days ago I was given a RioVolt SP250. For anyone unfamiliar with that model, it is a firmware-upgradeable CD-based *.mp3/*.wma/*.asf/*.cda player (the *.asf is audio-only; there is no video out jack). More formats will probably be added later, and I'm pressing for unencrypted ISO-compliant MPEG-4 *.aac myself. But I'm chasing rabbits... aside from my OTR collection, I also have an extensive (and eclectic) archive of music. This consists of somewhere over a thousand albums (on original CDs, that is), along with an equivalent number of unreleased/live performances showcasing those artists for which I have a particularly insatiable appetite (and when I trade the unreleased stuff, it's as lossless *.shn files - the *.mp3s I generate are STRICTLY for personal use!).

  When I compile an MP3-CD, my preference is to include an artist's complete discography (or to break it into logical chunks, such as Pink Floyd's Harvest/EMI catalog as opposed to their later Columbia offerings), or to present an entire collection in its original intended sequence (in the case of, say, "Ken Burns' Jazz"). Generally, I've found that most such collections would fit comfortably on six 80-minute audio CDs, if they could be seamlessly integrated into a single large playlist; that's equivalent to an eight-hour stretch of music. An 80-minute CD-R easily accomodates this at 192kbps CBR, with a little additional space to cover overrun or for whatever scans I choose to use as artwork.

  Anyone who's waded through all of the preceding ramble is undoubtedly beginning to form an opinion of what my commandline should include. My concern in encoding is the best quality for my chosen CBR bitrate; I'm not particularly concerned with speed, since I have a lot of patience.    For reference, I've set up RazorLame 1.1.5 with Dibrom's unofficial version of LAME 3.90.2.

  After a rough perusal of the included options, this was what I chose as a starting point for LAME experimentation:

    -b 192 -m j -p -c -q 0 --nores

  "-b 192" defines 192kbps CBR encoding, which allows me to reliably plan my compilations around the space available, and not wind up trying to trim them down to fit the available space (or find something else to fill up unexpected empty space!).

  "-m j" defines Joint Stereo, since (correct me gently if I am wrong, please!) Joint Stereo allocates a greater number of bits for sounds shared between both channels and becomes the equivalent of "True Stereo" as necessary.

  "-p" adds CRC error protection, which is probably unnecessary on a RioVolt, but I still find it a comforting thought. 

  "-c" marks the encoded file as copyrighted. Not necessary, of course, but it's my preference and the bit is dedicated to indicating copyright status regardless of whether it's checked or not (that is, it can't be used to store music).

  "-q 0" uses the slowest & best possible version of all algorithms (according to the "USAGE" file included with LAME). I've read several threads which imply this is somehow worse than "-q 2," but so far I haven't found any satisfactory explanation of why that would be the case. If anyone can CLEARLY explain the advantages or disadvantages of this selection, please do so!

  "--nores" disables the bit reservoir. This is to enable compatibility with true "gapless" encoding, since my understanding is that a small amount of the frame data from one frame may otherwise be stored in the previous frame. I encode albums/concerts as a single stream and then split them on frame boundaries, so that things like the second half of the Beatles' "Abbey Road" (or any one of the Grateful Dead's live concerts) will play back without that annoying little bit of audible silence between continuous songs.

  I have no need to use "--scale" since most of my music is already at the desired listening level, and when it is not I generally adjust my levels within the extracted *.wav files, rather than during the encoding process. Clipping should never be a problem.

  I have an effective hearing range in excess of 20kHz, so I'm loathe to apply any sort of frequency cutoff. Despite this I know I'll have to sacrifice a little in this area for space, and I'd like to retain as much of the aural spectrum as is reasonably possible given the rest of my listening requirements. Advice would be appreciated, if anyone (Dibrom?) could explain what the high quality algorithms will tolerate.

  I'm debating over whether or not to include "--strictly-enforce-ISO," as I want my discs to be compatible with whatever player I'm listening upon (since I occasionally visit friends with MP3-compatible DVD players), but I'm not sure how "strictly" such devices check the ISO format. (If anyone is considering purchasing a portable, I'll mention that my RioVolt hasn't shown problems with any *.mp3 file, regardless of ISO compliance, encoder or, as far as I can tell, anything else!)

  Also, I've seen "--nspsytune" mentioned a few times now, but if there's been a clear explanation of what it does and when it is appropriately used I somehow managed to miss the post. Could someone elaborate upon this setting? Thank you.

  Suggestions are always welcomed, as long as they are offered in good spirit. Happy (almost) 2002!

  Sincerely,
    - M.

192 kbps

Reply #20 –
Ok. I'll try adding what I have understood and learned. Please do correct my assumptions if I'm wrong.

First. I don't know if your Riovolt can handle VBR files, but I assume that it does.

1) So. There might be the experience that on AVERAGE the --alt-preset standard does equal around 192 kbs. If that would be true for all your albums then we could be happy, because then everybody could recommend that setting. If you have enough time, you could always try encoding your pre-selected eight hours of music pr CD-ROM and see if it would fit. If not, I guess I would recommend you to

2)  use ABR. The switch --alt-preset 192 should give an average much closer to (or below) the 192 you are aiming for while at the same time being better than CBR at 192. But if you really want to go CBR I can't help you with precise parameters. I would most likely just use the --alt-preset cbr 192 switch myself...


--
"In Xiph we trust"

192 kbps

Reply #21 –
Hi,

Quote
"-b 192" defines 192kbps CBR encoding, which allows me to reliably plan my compilations around the space available, and not wind up trying to trim them down to fit the available space (or find something else to fill up unexpected empty space!).


I'd go with abr, it gives you 192 kbps as final bitrate but using higher or lower bitrates during the sound.

Quote
"-m j" defines Joint Stereo, since (correct me gently if I am wrong, please!) Joint Stereo allocates a greater number of bits for sounds shared between both channels and becomes the equivalent of "True Stereo" as necessary.


Yes, but you must use --nssafejoint to avoid any "mistake". The default j.s. threshold of L.A.M.E. sometimes it's too low.

Quote
"-p" adds CRC error protection, which is probably unnecessary on a RioVolt, but I still find it a comforting thought.


NO! this is useless and wastes bits in another case they would be used to store sound. I really don't recommend you to use this setting.

Quote
"-q 0" uses the slowest & best possible version of all algorithms (according to the "USAGE" file included with LAME). I've read several threads which imply this is somehow worse than "-q 2," but so far I haven't found any satisfactory explanation of why that would be the case. If anyone can CLEARLY explain the advantages or disadvantages of this selection, please do so!


Many people claimed problems with -q 0. I'd go with -q 2. Faster, and no problems, at least for me.


Quote
"--nores" disables the bit reservoir. This is to enable compatibility with true "gapless" encoding, since my understanding is that a small amount of the frame data from one frame may otherwise be stored in the previous frame. I encode albums/concerts as a single stream and then split them on frame boundaries, so that things like the second half of the Beatles' "Abbey Road" (or any one of the Grateful Dead's live concerts) will play back without that annoying little bit of audible silence between continuous songs.


Another bad idea. You're gonna to waste a lot of bits, maybe the problem with gapless it's id3 tags. Try removing them, and listen if the problem is gone.

Quote
I have an effective hearing range in excess of 20kHz, so I'm loathe to apply any sort of frequency cutoff. Despite this I know I'll have to sacrifice a little in this area for space, and I'd like to retain as much of the aural spectrum as is reasonably possible given the rest of my listening requirements. Advice would be appreciated, if anyone (Dibrom?) could explain what the high quality algorithms will tolerate.


Well, at 192 kbps LAME lowpass at 18.6 - 19.2 kHz by default.


Quote
I'm debating over whether or not to include "--strictly-enforce-ISO," as I want my discs to be compatible with whatever player I'm listening upon


This setting only enforces a 7680 bit limitation on frame size, so you're only going to limit the reservoir. The MP3s created with LAME are totally "playable" on any ISO-compatible player.

I really recommend you to try

--alt-preset 192

I think Dibrom can you help you more than I in this subject

I hope you find my recommendations useful.

My kinds regards, have a happy new year!

192 kbps

Reply #22 –
For a portable MP3/CD player like the Mojo and the RioVolt, the best lines are

--alt-preset cbr 192
--alt-preset 192
--alt-preset standard

192 kbps

Reply #23 –
Hi again. Thank you for the suggestions! Let's see if I've got a better grasp on it now...

  First of all, the RioVolt does play VBR/ABR files, but support for them still feels rather sketchy. Meaning I get audio, but may or may not be able to seek properly within the file, etcetera. Also, because of the aforementioned DVD/MP3 players I might be using in other locations (very few of which support VBR, to date) I still think CBR is the better decision for my own archives.

  However, after studying the specs a little more, I realized this is not necessarily as sharp a limit on quality as I originally feared. From the "USAGE" file: "A 128 kbps CBR bitstream, because of the bit reservoir, can actually have frames which use as many bits as a 320 kbps frame. ABR/VBR modes minimize the use of the bit reservoir, and thus need to allow 320 kbps [max bitrate] frames to get the same flexibility as CBR streams."

  [By the way, amp, ID3 tags pose no difficulty for the RioVolt. It supports both ID3v1 and ID3v2 - you can tag your files however you prefer, and the decoder parses the tag properly (that is, it knows not to try and play that information as audio).]

  This gets back into why I originally thought to turn off the bit reservoir (using "--nores"), since I did not want to accidentally split an extended frame when I broke a continuous stream into individual tracks. But then I found something else in the "--longhelp":

  "--nogap" denotes gapless encoding for a set of contiguous files (that is, files sent sequentially through the encoder). How long has this been in LAME? I've been told Blade already had something like this, but I had not read anything about LAME implementing it.

  So (again, correct me if I'm wrong) my understanding is that as LAME approaches the end of the first *.wav it pre-reads a slight amount of the next sequential *.wav, and encodes to the end of a full bit reservoir or frame before closing one stream and beginning the next. Dibrom, could you confirm or clarify this explanation please?

  This means - if it works properly - that I no longer need to encode an album as a single stream and split it; also, in RazorLame I should be able to visually arrange the files in their proper encoding sequence and they will *automatically* be gapless!

  Apparently one also must include the "--nogapout" switch to redirect gapless output to the proper path. I tried using RazorLame's internal redirect, and the files still wound up in the source directory. Is this a bug, or simply a necessary part of the gapless encoding mechanism?

  Now, assuming I use the recommended preset for 192kbps CBR encoding, my command line would look like this:

  --alt-preset cbr 192 --nogapout [dir] --nogap

  Is there any reason not to use this combination? Again, I'm open to suggestions, and appreciate the willingness of the forum to entertain my curiosity. 

  Sincerely,
    - M.

192 kbps

Reply #24 –
I don't know much about '--nogap'. I think it's preliminary support since LAME 3.89.