I have found that some actually lower quality values produce higher bitrates in Nero Digital Audio Reference MPEG-4 & 3GPP Audio Encoder (Version: 1.1.34.2, Build date: Aug 6 2007)
I was just trying to get the lowest possible quality while not introducing any crosstalk between the channels in a test sample, when I found that the bitrates where not decreasing.
The -help switch says that the value of -q "is a floating-point number in 0...1 range".
0.2185955271124839644 is a floating-point number, it's lower than 0.22, and it's producing bigger files in all cases I tested.
So... there's something bad there
May I be doing something wrong?
Or is this a problem in the encoder?
Thanks for the attention, I hope it can be fixed.
And sorry for my poor English!
EDIT: BTW, "target quality" mode is the highest quality/smallest file mode available, isn't it? Or may two-pass target bitrate mode be better in some cases?
Isn't it possible that the larger file is of lower quality?
Isn't it possible that the larger file is of lower quality?
Why would something like that happen?
And, if that where the case, then that is some serious bug in the encoder :S
Isn't it possible that the larger file is of lower quality?
Why would something like that happen?
Because quality and file size are not the same thing. You didn't specify a file size, you specified a quality setting, and while the two are generally correlated, they are not absolutely so.
And, if that where the case, then that is some serious bug in the encoder :S
I doubt its a bug. Probably just the uncertainty in predicting what the bitrate will be. Use a two pass encoder or CBR if you must control bit rate.
Just curious but why would someone use -q 0.2185955271124839644 instead of just using -q 0.22 for encoding needs?
Edit: Punctuation
So... there are quality values that produce bigger files of lower quality?
Doesn't sounds very efficient to me. And that's EXACTLY what I'm looking for.
I don't need to predict a bitrate.
I just need to store lot of music in very little space with an acceptable quality.
The HE-AAC decoder in my cellphone produces very strange and ugly artifacts at certain quality values, that's the reason why I want to use such a precise value.
But if using a higher quality also saves me space, then it makes absolutely no sense!
How can I find the most efficient compression, then?
Any suggestion?
Or will I have to test all the possible combinations?
To start, I assume that "target quality" mode is more efficient than "target bitrate" even in two-pass, and that both are way better than constant bitrate. Right?
Just curious but why would someone use -q 0.2185955271124839644 instead of just using -q 0.22 for encoding needs?
That's an excellent question...
The answer is that I have really REALLY little space and lot of songs to store, so even the slightest savings are useful.
And why not use a quality way lower then? Because the decoder in my device sucks and produces really ugly and big artifacts at some lower qualities, and at even lower than these (like with enabling Parametric Stereo) is just too low quality.
That's the reason I want such a precise setting, (in THEORY) to get the smallest file possible that sounds good.
Why would you need any kind of stereo for your cellphone?
Why would you need any kind of stereo for your cellphone?
Erm... because... songs are recorded in stereo, it plays stereo sound, it has stereo earphones, and I have a pair of ears.
Mono sounds pretty bad, specially on some songs.
Also, my previous cellphone was mono, and I want to take advantage of the upgrade.
So... there are quality values that produce bigger files of lower quality?
On some files, probably.
Doesn't sounds very efficient to me. And that's EXACTLY what I'm looking for.
I don't know why you'd think that.
The HE-AAC decoder in my cellphone produces very strange and ugly artifacts at certain quality values, that's the reason why I want to use such a precise value.
I doubt it has anything to do with the q value. Probably just has an overflow or similar bug somewhere, and certain files trigger it.
So... there are quality values that produce bigger files of lower quality?
On some files, probably.
No, that happens in ALL files, I tested a BIG set.
Doesn't sounds very efficient to me. And that's EXACTLY what I'm looking for.
I don't know why you'd think that.
Because it is wasting bits encoding something that does not raise the quality.
The HE-AAC decoder in my cellphone produces very strange and ugly artifacts at certain quality values, that's the reason why I want to use such a precise value.
I doubt it has anything to do with the q value. Probably just has an overflow or similar bug somewhere, and certain files trigger it.
It happens in ALL the files at certain quality levels.
Hope this clarified something
For different expected bitrate ranges the encoder uses different parameters that produce different results. On the switch between parameter sets there might be "glitches" in the bitrate. I already explained before that in the last version we brought the gaps between the sets together much closer, apparently in some cases even too close... The old encoder made jumps of ~10kbps between sets, that was also not good (although for some reason less people complained )
Thanks for the info. I understand now.
In that case, what are "safe" quality values?
I mean, what numbers have been exactly tunned?
Up to 2 decimals?
Yes for finding these mapping tables 2 decimals are used.
Maybe for next version I will spend some more time to do it even more accurately
Thanks a lot!