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: best possible 320CBR (Read 6935 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

best possible 320CBR

Hi

I'm pretty new to the whole EAC and LAME encoding and ripping. I've recently decided to re-rip all of my music in CBR 320 (not fussed about file size or time taken to rip).
But as i'm awfully fresh to the program i'm not entirely sure what to put in the code line for best 320cbr results?

Tips and advice greatly appreciated


Cheers

best possible 320CBR

Reply #1
-b 320, 320 kbps is far beyond the level of transparency already.*

*except for problem samples
It's only audiophile if it's inconvenient.

best possible 320CBR

Reply #2
so this is what it is at the moment:

%islow%-V 5%islow%%ishigh%-V 2%ishigh% --vbr-new %source% %dest%

I'd just change the vbr-new to b-320?

best possible 320CBR

Reply #3
use
-b 320
just that, and nothing more

best possible 320CBR

Reply #4
Or, --preset insane.

best possible 320CBR

Reply #5
I'm pretty new to the whole EAC and LAME encoding and ripping. I've recently decided to re-rip all of my music in CBR 320 (not fussed about file size or time taken to rip).

First things first: the best that you can do is to rip in a lossless format (e.g. FLAC), save the resulting files and transcode to mp3 later. Ripping directly to lossy is a flawed process and not because of audibility of compression artefacts @320 kpbs, but because a lossy file is not a good starting point for further processing, like for example making a lower bitrate version for portable, maybe using a different codec etc...
... I live by long distance.

best possible 320CBR

Reply #6
says


the external compressor returned an error!

Options: -b 320

then the file destination

best possible 320CBR

Reply #7
To clarify, you always need to have %source% %dest% or the appropriate variant thereof at the end of your command line, regardless of which encoder is being used.

-b320 %source% %dest%

See our Knowledgebase and EAC’s FAQ for plenty of information on other basics like this and more advanced concepts.


best possible 320CBR

Reply #9
"-b 320  -q 0" theoretically gives better quality than simply "-b 320", because by default -q is 2

best possible 320CBR

Reply #10
If I’m not mistaken, the general advice around here is that such theoretical benefits are not significant enough to recommend that users deviate from the default setting, unless supported by a double-blind test of course. And every time this comes up, I have to say that I seem to recall someone pointing out that -q0 may, at least in the past, possibly provide slightly worse quality. Sadly, I do not have a reference to hand. But again, the default is there for a reason, and there are more pressing things to recommend, such as using VBR to avoid wasting 320 kbps on supposed ‘quality’ that is irrelevant once transparency is attained, which would probably occur at a sizeably lower mean bitrate than 320 kbps.

best possible 320CBR

Reply #11
If I’m not mistaken, the general advice around here is that such theoretical benefits are not significant enough to recommend that users deviate from the default setting, unless supported by a double-blind test of course. And every time this comes up, I have to say that I seem to recall someone pointing out that -q0 may, at least in the past, possibly provide slightly worse quality. Sadly, I do not have a reference to hand. But again, the default is there for a reason, and there are more pressing things to recommend, such as using VBR to avoid wasting 320 kbps on supposed ‘quality’ that is irrelevant once transparency is attained, which would probably occur at a sizeably lower mean bitrate than 320 kbps.

Indeed, there was a time when an attempt to increase quality with the -q0 switch apparently was unsuccessful and somewhat buggy. Those days are thankfully long gone, but still the use of -q0 is highly questionable. Appart from being much slower, it gives little or no actual increase in quality.

 

best possible 320CBR

Reply #12
Frankly, I'd recommend using halb27's 3.100i/j tweaked version of LAME, and using -V0+ rather than CBR 320.  This will give you nearly 320 kbps (317-320 on average) and yet takes advantage of an improved version of LAME's already pretty good VBR processing.
In general, VBR > CBR at the same overall bitrate because VBR allows bits in a given frame to be "donated" to more difficult adjacent frames, while CBR just wastes space in less difficult frames.  -V0+ allows up to 450kbps on short frames, if I remember correctly.

best possible 320CBR

Reply #13
And, once again, I would advise against recommending a specialised fork of LAME to a user who is still coming to terms with the basics. Unless double-blind testing verifies that (1) VBR with a mean bitrate below 320 kbps is insufficient and subsequently that (2) 320 kbps encoded by vanilla LAME is also lacking somehow, i.e. not already overkill, I do not see much purpose to recommending an alternative version.

I do not mean to downplay the work of halb27, as having another option is almost always a good thing, but it strikes me as something for specialised users who know what they are doing with the format and/or are especially worried about the issues it targets—not someone who apparently has not evaluated the drawbacks of 320 kbps CBR when compared to VBR or, indeed, lossless.

Heck, if the concern is securing the beneficial techniques of VBR in a quasi-CBR context, standard LAME already can be made to encode to CBR with the VBR algorithm, but again, I see no point in recommending even this officially possible variant of 320 kbps when no evidence has been proferred that normal 320 kbps is necessary here.

best possible 320CBR

Reply #14
And, once again, I would advise against recommending a specialised fork of LAME to a user who is still coming to terms with the basics. Unless double-blind testing verifies that (1) VBR with a mean bitrate below 320 kbps is insufficient and subsequently that (2) 320 kbps encoded by vanilla LAME is also lacking somehow, i.e. not already overkill, I do not see much purpose to recommending an alternative version.

That's fair.  In all honesty, I find even -V0 -q0 in vanilla LAME 3.99.5 to be more than sufficient, and (for my poor hearing) it is just as transparent as CBR 320.  That may be something the OP wants to look into as well.

Philosophically, I think it's better to lay all the options out on the table for a new user, and then let him/her decide which approach is best for their specific need (while asking plenty of questions of the more experienced).  But, it's probably best not to get into that topic here, as it could derail the conversation.


best possible 320CBR

Reply #16
@ greynol

I assume you meant "prompted"?

@ BFG

There's no reason to use -q 0 with the new VBR mode. It's the default, so the switch is superfluous. If memory serves, multiple q values also provide identical results with --vbr-new, although I don't remember the breakdown of values.


best possible 320CBR

Reply #18
An obvious first step would be to tell us whether the same problem occurs when you play the CD itself or rip it to an uncompressed format such as WAV. You do not seem to be doing anything wrong, so we need to explore all possibilities that might be causing the problem, starting with the simplest scenario of the CD being at fault.

In all honesty, I find even -V0 -q0 in vanilla LAME 3.99.5 to be more than sufficient, and (for my poor hearing) it is just as transparent as CBR 320.
Can I ask whether you tested lower settings and found them to be non-transparent? Most users, find something like -V2 to be fine for most material, and some can go lower than that, so I have doubts that the word “even” is necessary in your statement! You question your hearing, but if settings below -V0 fail to satisfy it, it’s probably better than average.

Quote
Philosophically, I think it's better to lay all the options out on the table for a new user, and then let him/her decide which approach is best for their specific need (while asking plenty of questions of the more experienced).  But, it's probably best not to get into that topic here, as it could derail the conversation.
Whilst I agree with you about derailing, it is still somewhat relevant here. I agree to a point that various options should be noted, but I personally feel that when a user is starting from the beginning, it is best to stick with standard and/or basic features. If those are shown to be insufficient, more specialised approaches can be explored. In this case, I have also been trying to cast a sceptical eye on whether 320 kbps is necessary. I think learning how to use basic settings and then considering VBR and lower bitrates, and the testing methods that could verify them, will be more beneficial to Charmangus than concerns about short blocks, isolated samples of single instruments, and whatnot.

best possible 320CBR

Reply #19
In general, VBR > CBR at the same overall bitrate because VBR allows bits in a given frame to be "donated" to more difficult adjacent frames, while CBR just wastes space in less difficult frames.  -V0+ allows up to 450kbps on short frames, if I remember correctly.


320 is the highest rate allowed in the mp3 standard.  While lame has an option to go higher, you are playing with fire because many (most?) players won't handle it.
If by "donate to adjacent frame" you mean bit reservoir,  CBR can do that too.

best possible 320CBR

Reply #20
... -V0+ allows up to 450kbps on short frames, if I remember correctly.


320 is the highest rate allowed in the mp3 standard.  While lame has an option to go higher, you are playing with fire because many (most?) players won't handle it.

No fire play, just bitreservoir used the maximum possible way so that any usual player can handle it.
The common misunderstanding: frame (container) bitrate is 320 kbps maximum according to the mp3 standard, but locally (due to bitreservoir) bitrate can be more than 500 kbps.
lame3995o -Q1.7 --lowpass 17