Meaning of Q settings

Topic: Meaning of Q settings (Read 3703 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.

Meaning of Q settings

2003-06-13 15:52:48

When I first started using Ogg Vorbis a couple of years ago one of the things that interested me was the -q setting. As i recall, the justification was that bitrate doesn't really matter - qualification: Mostly people don't actually need a file that is exactly 128kbps (or whatever target) - they want an acceptable level of quality at a reasonable size.

So the idea of the -q setting was "Pick the setting that gives you the quality you want, and as the codec develops output will be tweaked to reduce the size of the file at that quality level"

With Garf's improvements (which I think are great and am in no way knocking!) this argument seems to have been weakened. Now it seems that, across versions, all you can assume is that q6 is better than q5, but not as good as q7.

Any thoughts?

Cheers, Paul

Meaning of Q settings

Reply #1 – 2003-06-13 16:10:13

Well, how should one measure the quality of a file ? Difficult, but let's assume we can. At least sometimes we know the quality *goal* and can estimate whether it's met or not.

Example:
- for musepack, the quality level goal of --quality 5 is transparency under all reasonable listening situations.
- for lame, goal is as transparent as it gets (within the limits of mp3) at --alt-preset standard.
- for vorbis, there's no clear description for any of the quality levels. Thus the slight confusion.

Let's stay genetic. Let us just consider a given codec, running at a given quality level.

In theory there are 4 possible outcomes:
- quality goal is met exactly, but no more. Thus no improvement is possible, except for lossless ones (ie: file format, entropy coding, etc.) - that's every lossy codec developer's wet dream. Even lossless codecs can't put here, because they do exceed the best possible quality goal (=always transparent)
- quality goal is constantly exceeded. This means: Bitrate = (Useful bits + Useless bits) / Time. You'll expect further versions to reduce the bitrate consistently. All lossless codecs (and possibly a few near-lossless ones) are in this category.
- quality goal is constantly missed. Thus bitrate should be raised more or less consistently throughout the recording, if the psymodel remains the same.
- quality goal is sometimes exceeded, sometimes missed. This is by far the most common situation, hard to get rid of without insane bitrate increases. So either bitrate can be consistently increased (thus exceeding quality goals), or further versions must be made more clever (better bit allocation, better psymodel).

Of course, there can be lossless improvements to a codec, but they are usually minor and affect bitrates only.

So, if we assume that "Vorbis -quality 6" is supposed to get a "generally transparent" quality rating, we can suppose (for example) that Garf increased the bitrate in GT3 to match the target better, in terms of time resolution.

Maybe in a few months, the bitrate will drop again, yet sustaining the same quality thanks to more clever pre-echo detection and "hard passage" selection

In quality-oriented codecs (ie: musepack and the higher-bitrate part of Vorbis) we can replace numbers with names (thus describing the goal of each level). With a good codec, to be safe you only need to pick a level that's slightly over your target.

I'm sure there still are huge improvements for codecs; take a 64kbps WMA for example, it might sound imperfect, okay. However, I bet with some more research we'd come to the conclusion that the file is still über-transparent 1/3 of the time.. so the perfect codec would know it, and use yet more efficient file formats.. so 25kbps could be enough in easiest passages, even though fatboy would use alot more B)

Also, finding several notes coming from the same instrument *should* be exploited by codecs.. I mean, there's probably much, much redundancy (or perceptually near-identical pieces in music) to be discovered and exploited still.

Edit: modif'd almost everything.

Meaning of Q settings

Reply #2 – 2003-06-13 16:47:57

Quote

So the idea of the -q setting was "Pick the setting that gives you the quality you want, and as the codec develops output will be tweaked to reduce the size of the file at that quality level"

With Garf's improvements (which I think are great and am in no way knocking!) this argument seems to have been weakened.

Only because I had no time to do the needed shuffling, i.e. GT3 should just remap settings a bit to do as you describe.

Meaning of Q settings

Reply #3 – 2003-06-13 18:42:53

Interesting discussion NumLOCK!

And thanks for that Garf, it makes perfect sense

Cheers Paul

Meaning of Q settings

Reply #4 – 2003-10-31 22:06:09

In the Riovolution forum, someone asked about the same things in this topic. I am wondering if I explained it correctly, can someone read through what I posted, and tell me if I've got the theory down? Thanks

Quote

Quote
However, the point of the "q" thing to Xiph, as I understand it, is to decrease file size while maintaining the same quality level for whatever q-number. So this goes against that. But whatever.

Yeah, that is what they are working for. Ultimately, the bitrates related to each quality setting should drop, as the encoder is improved. I think within the lifetime of an encoder, this should always hold true. Ah, but not all of Garf's tweaks were bitrate related, so simply a higher choice of quality (eg bitrate) in the standard Vorbis encoder will NOT directly achieve the same results as the gt3b1 encoder.

So theoretically, to fit the goal of Xiph, what must be done is find out where these gt3b1 settings have slightly better or same quality AND lower or equal bitrate compared to the standard q values, and replace them with these. It is hard to judge if something is of equal quality or not, and so it is easier said than done . From what I see, if they replace matching bitrates in the standard Vorbis with ones in the gt3b1, and then shift the q values to the left by 20kbps plus whatever quality they gained by the non-bitrate tweaks, it would be pretty close. But then the q values would not have their nice 5=160kbps, 6=192kbps, etc, relationships, but I guess that shouldn't matter.

Notice