[vorbis-dev] Re: Major quality decrease in RC3 compared to RC2

[Dave Hooper]

> The thing that concerns me about the -q value is now the filesize is
> unpredictable?  Or am I wrong.

Quite right.  The filesize is now a function of the quality setting and the
complexity of the music.  In exactly the same way that MP3 software (e.g.
MusicMatch) uses numbers between 0 and 10 to abstractly define the 'quality'
(and implicitly the filesize) when using a VBR mode.

> If I made a 128kbps mp3 would I have to re-encode the ogg like 3 times
> with different -q settings before I guessed the right value to make it the
> same filesize? (ie for size/quality comparisons, or trying to squeeze the
> data into a certain fixed size of limited hardware memory).

To be blunt, yes.  Vorbis won't know 'in advance' how much data is needed to
encode the music at the specified quality until it has tried it, because in
essence it won't know in advance how complex the music is until it has heard
it. A quick-and-dirty way of squeezing the data in a fixed amount of ram
would be to specify a maximum bitrate when you encode, but the -q modes will
be better.
I don't see any compelling argument for oggenc to be given a 'maximum file
size' parameter.  A simple reencoding batch script can do this, as you
suggested. If you feel that this is an inefficient way to do things, or you
want faster offline encoding, then you'll need to opt for a more restrictive
encoding scheme with more predictable file sizes, e.g. managed bitrate
modes.

D

<p>--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'vorbis-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.