hi!

i have recognized the following and have no explanation. please help.

i have ripped a cd to my hd in .wav. with the latest audiograbber version.
then i encoded with the external lame 3.97 and the following setting:
%s %d -b 320 -q0, which took very long, approx 1 min/track but imho results in best possible quality,

after that i encoded again with the following settings
%s %d -b 320 -q9, this time the encoding process was much much faster, just a few sec per track.

now guess what.... the filesize of both endoded method files is exactely the same even to the last bit. + i can't here any differences?
?????????????????????????

do you experts have an explanation or an advice?
i don't want to get in a discussion about a better format than .mp3, cbr or vbr or about joint stereo or stereo, i just want to know why the size is exacely the same?
i am converting a lot, so a faster speed is appriciated, but quality is above all to me.

thanx for your ideas in advance...

cheers
chill

If you can't hear a problem then why does it matter? Quality doesn't seem to be at the top of your priorities or you'd be using VBR (for which LAME is highly optimised) with Joint Stereo, ie, any of the -V settings, but as you've banned any talk of such things, maybe I shouldn't have mentioned it.

Try reading the Hydrogenaudio LAME WIKI.

Cheers, Slipstreem.

because you said so. Hint: -b320

The file is CBR (constant bit rate), the input file has the same duration so logically if you multiply the same duration with the same bitrate you should get the same size (ignoring other non-audio data present in the MP3 file)... Theoretically, you should get the same size even with a completely different input file if it has exactly the same length.
The -q option just specifies precission (and complexity) of some MP3 algorithms.

Likewise, you may wash your hands five seconds or five minutes but washing for longer than one minute is not likely to give you much additional benefit.

@slipstreem
even with a vbr you can't get better results than 320. so what should be the problem here if filesize doesn't matter.
i need to stay with mp3 otherwise i would change to flac.

@robert + martel
sorry guys i don't get you.
ok! the specified size is 320 cbr.
but which influence does the q value exactely have?
the standard qval=3 in setting -b320, at least this is what lame shows.

so what sense does it make to stuck to a low qval, if the result with a higher qval e.g. 9 is exactely the same, with a big advantage in speed.
???

cheers
chill

simply put ... a lower q value might - on some occasion - lead to better quality files ... but you did not run into any problematic pieces of music yet which might benefit from lower encoding speed and lower q value.

If filesize doesn't matter then why are you using a lossy codec?

Are you honestly saying that you can hear the difference between CBR320 and VBR at -V0? I very much doubt if you'd hear the difference at -V3, but you'd need to test this for yourself to be sure. It's no good making assumptions and ignoring the advice of people who've spent years using the encoder.

MP3 is about saving bits whilst preserving quality. CBR320 defeats the object of using MP3 in the first place to a large degree.

Cheers, Slipstreem.

@slipstreem
again...
1. i need to stay with mp3.
2. i do not doubt that you can't here any difference at v0 or even v3.
but this is not my question.

cheers
chill

I doubt it. At least CBR and VBR modes treat sfb21 problem in different ways.
(from LAME help: "-Y [switch] lets LAME ignore noise in sfb21, like in CBR")


Low qval -- more complex algorithms, more efficient encoding. High qval -- simpler&faster algorithms, less efficient encoding.



It shouldn't be the same. Maybe you cannot hear difference between them, but they are not identical.

this is exactely the point, i can't here a difference in 320 cbr q0 and q9 + the filesize is exately the same to the last bit.
so my conclusion was that there is no difference at all, even though i can't here a difference.

cheers
chill

There is no difference at all because you didn't hear a difference?

Did you at least do a file compare or a comparison of the decoded output in order to see whether or not there actually was a difference?

@greynol

i did a file compare with the encoded .mp3's.
all files were exactely of the same size.


i am just wondering that there is no difference in filesize but that big difference in speed.

so what would you guys suggest to set for me.
-b320 qval=?....

cheers
chill

I think you need to go a bit farther than simply looking at a file's size.

so your advice is to use a lower qval?
which?

My advice is to use a setting that delivers a small file that is transparent to you, to be determined through bind testing. I'd first try -V3 or -V2 and not play with the -q setting.

thanx for you radvice but again i want to stuck to cbr 320.

so what would you recommend in combination with this setting?
or would you just use -b 320 with no kind of additions?

cheers
chill

try to encode one file with '-b 320' settings, and another with '-b 320 --lowpass 6 --resample 44' (I assume your input is 44.1 kHz). Compare filesizes and quality .

Edit:clarification

@lcqcl
?

Why when all logic and combined knowledge here suggests otherwise? Or do you know how MP3 works better than we do? This forum is the home of LAME development you know.

Your arrogance and ignorance will do you no favours here.

Cheers, Slipstreem.

:-(

Ok, I give up.

Use

i think you have to agree that the lame encoder is not able to encode better than 320?

so my logical result is that i stuck with 320 at a constant bitrate cause filesize doesn't matter, even though it is nonsense or a waste of space.

and again i agree that probably it is not possible in a blindtest to hear a difference between 320cbr and -v.

so where is the problem?

cheers
chill

Try

I'm joining Greynol. See ya.

Cheers, Slipstreem.

@greynol

preset insane uses qval3?
right?

cheers
chill

btw. do you guys use 3.98 already?
would you recommend to switch to 3.98 or to stay with 3.97?

cheers
chill

@ chill
If you want to properly compare two files, you may want to use a hex editor, for instance "HxD", or, better still, a file comparison program. An example of the latter is "KDiff3", a free software which runs on most platforms and also handles binary files.

@slipstream

this is what i have read on the wiki site
"Remarks

* The rule of thumb when considering encoding options: at a given bitrate, VBR is higher quality than ABR, which is higher quality than CBR (VBR > ABR > CBR in terms of quality). The exception to this is when you choose the highest possible CBR bitrate, which is 320 kbps (-b 320 = --alt-preset insane), but this produces the largest filesizes for doubtful audible benefit. "

so i don't understand the problem with going 320 as filesize, once again, is not a matter.
my matter is speed, but not over quality.
so if you guys say that there is a difference between q9 and q0 in quality, i will choose a lower value.

cheers
chill

@gnypp45

thank you for your programm tips. i guess this would be the right way.
but honestly this is too much effort for my needs.

anyway thanx...

cheers
chill

The simple fact of the matter is that you are extremely unlikely to hear any difference in quality between CBR320 and any of the higher -V settings for VBR encoding. LAME has been specifically tuned over a very long period of time to produce the best results in VBR, so it makes common sense to at least try it rather than dismiss it because your own illogical and misguided ideas and lack of personal knowledge regarding MP3 encoding with LAME tells you otherwise.

We have, on average, one person a week coming to this forum and telling us that we're all a bunch of retards and have absolutely no idea what we're talking about when it comes to optimum LAME encoding settings, and I think I can speak for many of us when I say that we're sick and tired of it. VBR is the way to go if your hardware supports it. Any hardware that doesn't support VBR is broken as it's been part of the standard since the inception of MP3 back in 1991.

LAME has been specifically tuned to take full advantage of VBR encoding over the years and is highly likely to produce results that are transparent to you at well below an average of 320Kbps. If you choose not to take advantage of this then that's entirely your loss. Stop ignoring us or ridiculing us for having a much better understanding of the MP3 format than you do. You're just making yourself look incredibly stupid to those who genuinely do know better.

Try VBR encoding at various values of -V and confirm for yourself whether or not you can hear a difference via an ABX comparison test. Most people find -V3 (~175Kbps) to be totally transparent under almost all circumstances, and only a fool throws unnecessary bitrate at a problem in order to achieve absolutely nothing when using a lossy codec. Use logic and your own ears to determine what is best for you personally.

Your arrogant attitude toward those that have helped to tune LAME for optimum performance over many years of intense research leaves me almost speechless to be honest. It shows an incredible level of disrespect. Listen and learn, or prepare to have your irrelevant questions ignored by those who genuinely do know better.

Cheers, Slipstreem.

my intension never was to be disrespectlese, cause i have a deep respect to those who constantly tune something to improve the it.

BUT i had a simple question and i am very sad that it is not possible to get a simple answer and getting into a nowhere leading discussion.
:-(

cheers
chill

You should just forget about the "q" setting altogether and use the setting proposed by LAME (default). You're giving it far too much attention.
Read again my sentence regarding washing hands, perhaps you will get the idea what the "q" option does.

The simple answer is, that the quality might be eventually, in some cases, mathematicaly be bether, or not!

But think about that:
If a tree falls in the forrest and nobody hears it, does he make a sound?

ok!
so i will stuck to the standrad -b320 settings with no kind of switches at all.
one more:
what does
"assunming raw pcm input file: forcing byte"
mean?

this is what the encoder shows in the headline during conversion.
is this ok? or am i doing something wrong?

what about 3.98 and cbr? do you guys recommend it above 3.97?

cheers
chill

May I ask you, what do you use as a frontend to LAME?

The "assuming raw pcm..." usually comes when feeding LAME via STDIN. If it had a proper WAV/AIFF header, LAME (3.98) would recognize it. Without additional information, as in RAW PCM files, LAME can only guess how the input data is organized.

i am using audiograbber 1.83.1 with external lame 3.97

due to your given information i guess that this assuming line is alright.
right?

cheers
chill

please answer....

is the assuming line right if i simply grab from cd?

cheers
chill

It's been round about 9 years ago I once used AudioGrabber, so I'm not sure about what it's doing. In the worst case (a) the encoded mp3 sounds like static noise. In a not so worse case (b) the WAV header will be interpreted as sound data, resulting in a plopp sound at the beginning. If it's configured right, it will be ok.
Case (b) should be no problem when using LAME 3.98.

i want to show you the window i see during encoding, including the assuming line.... forcing byte swapping....
unfortunately i can't add pics.

this is what the window during encoding says using external lame 3.97 and audiograbber:

-------------------------------------------------------------------------------------
Assuing raw pcm input file : Forcing byte-swapping
Lame 3.97 32 bits (http://www.mp3dev.org/)
CPU features MMX (ASM used), SSE (ASM used), SSE2
Using polyphase lwpass filter, transition band 20094Hz - 20627 Hz
Encoding (stdin) to (stdout)
Encoding as 44.1 kHz 320 kbps j-stereo MPEG-1 Layer III (4.4x) qval=3
--------------------------------------------------------------------------------------

can you guys tell me if everything is ok for a cbr320 setting?

cheers
chill

My guess:
The checkbox "Ecoder is capable of usin stdin/stdout as datastream" is marked?

@start78

thanx for your answer.
your guess was right.
but "encoder is capable...." has to be marked, otherwise it is not possible to convert directly. right?
does it make a difference in the encoded file? or is it ok to have this checkbox marked?

cheers
chill

Have a look at the "manual" in the german Audiograbber forum (as you should have already done before asking any questions about Audiograbber). It's called "Audiograbber in 4 Schritten".

There we recommend not to encode directly to mp3.

And before you ask: "Assuing raw pcm input file : Forcing byte-swapping" is one reaseon...

Using CBR at 320kbps is a complete waste of space. Lame 3.98 is there and it's ridiculously good. I have ABXed several songs using Lame3.98 and couldn't differentiate them even at V6. If you don't care at all for space, stick to V0. Like everybody here have said using CBR at 320kbps is completely nonsense and stupid.

@start78

fist thing i have read is when starting with audiograbber indeed was "Audiograbber in 4 Schritten".
i have recognized the following...
using the directly mode no matter if you are using the internal or external encoder, results in a file with the following attributes from your recomended software EncSpot:
Psycho-acoustic Model: gpsycho
Safe Joint Stereo: no
ABR Bitrate: Unknown
Lowpass Filter:Unknown
Input Frequency: 32kHZ or less (even though other Programms are showing 44.1 kHz)

using the encoder over .wav:
Psycho-acoustic Model: nspsytune
Safe Joint Stereo: yes
ABR Bitrate: 255 or more
Lowpass Filter:2500
Input Frequency: 44.1 kHz

Now my questions are:
1. What is the exact difference of both modes in a quality aspect?
2. If it really is converted in an other quality using the direct way, or if it is just simply not shown correctly in EncSpot?

cheers
chill

so isn't there an explanation for the above shown data by EncSpot?
What is the difference of the result of a file encoded with and without having marked:
"Ecoder is capable of usin stdin/stdout as datastream"?

cheers
chill

Answers in no particular order:

1. The link (which is pinned to the top of the MP3 forum) to the official recommended LAME Settings. Please consult the information here for recommended settings for LAME, for your particular goal.

2. Math time. 320 kilobits per second x 100 seconds = 32,000 kilobits. Regardless of the state of those 320 kilobits per second (1's or 0's). Your files may be the same length, but the content is different.

3. Perform a file comparison with this tool.



Since the expert opinions on these questions are out on this board (usually pinned to the top of the relevant forum), let's start with this question: What are you trying to accomplish? What is your goal/use for these files?

@Thanru

i have no specific goal with these files i simply convert from cd put the mp3's to my archive and play them most of the time with traktor dj studio. i have to stuck to mp3 format cause of other reasons.

last weird thing to me is my above question, about the difference of converted files using stdin/stdout or over .wav.

cheers
chill

If I'm understanding your question correctly, this should help.

First, let me restate the question to be sure I know what you are asking.
"What is the difference between files encoded using stdin/stdout versus a temporary wav file?"

The answer to that question is that there should be no difference. The PCM information being passed to the encoder will be exactly the same.

As long as your encoder allows the use of a data stream as input, encoding is more efficiently accomplished (in terms of overall computer resources) compared to the use of a temporary input file.

Please see this article for more information.

It would appear as if Audiograbber is using different settings to convert the files (vbr-old vs. vbr-new?).

I'd use a newer ripping program, personally.

thanx for your answer. this is what i was thinking too, but the encspot software shows the above differences of the files. don't know if these are really different, or if encspot is simply not able to show the same values when encoded over .wav, because most fields in encspot say "unknown", also with the directway safe joint stereo is not used, with the method over .wav it is? now i am confused if it is wrong to convert directly.
any other comments here?


which ripping program would you recommend. eac e.g. imho and for my needs has far too many options, this is why i like audiograbber. simple and effective in use, and of course you can use an external encoder you prefer. also the tagging management is quite easy.

cheers
chill

...yet it appears to be causing you trouble.

The other extremely popular option here is dbPowerAmp. Either it or EAC should be easy to find information on here at HA.