Quality setting being equal, from the encoder having to allocate more bits to encode a particular source file, it does not follow that the resulting lossy file is any farther removed from its source than is a file of a lower bitrate from its source. It simply means the encoder judged it required more bits to attain the same (approximate) quality. Thatís the entire point of settings based on quality rather than bitrate, after all!

Ok that is true, but it is reassuring that the encoder needed fewer bits to handle a particular sample: it's a sign that it can be approximated more efficiently with the encoder used, which is a good thing, rather than something to be worried about. That was my main point.

QUOTE (dv1989 @ Jun 10 2011, 01:30)

Way off track, though thereís little point going into great depth (as if I even could!) when thereís bound to be plenty of documentation on VBR explaining its actual rationale. But in short: The best lossy encoder in the world would still benefit from a VBR model because all passages of audio are not created equal. It has nothing (necessarily) to do with inherent incompetence of either the encoder or its format as a whole.

Of course, the whole point of music is that it isn't just one sine wave for about 5 mins, in fact CBR is a pretty dumb idea, apart from the fact that it is the easiest to implement, and you know exactly what the filesize will be in the end.

When I say deficiencies I mean, say for example the encoder can only represent everything sinusoidally, it would not be able to represent a square or triangle wave in terms of sinusoidal waves, so it would have to increase the bitrate to accurately represent that, but if the encoder didn't have that deficiency and could just switch to representing things in square waves, it would not have to increase the bitrate at all. So in a way, VBR tends to be a cheap work around of sorts, as I'm pretty sure a lot of the variation in bitrate could be removed if more flexible algorithms were introduced into the encoder. Therefore in today's context, a higher resulting output bitrate is the sign that it is more likely that there is a part of the music that the encoder can't handle very well with it's current algorithms, which means it's more likely part of the music was not as accurately represented. But as you mention, a perfectly flexible encoder would still have a VBR, as the music itself has varying complexity, but vorbis is not an infallible perfectly flexible format.

=> overall perceived quality = (effectiveness of encoder)/(1-(compression ratio))Which works for either the whole file, or just a sample of it.

Therefore, since the quality is to be a specified constant, if the bitrate decreases and compression ratio also decreases, the effectiveness of encoder is higher. Which is basically just a mathematical way of saying what I said in my first sentence. Given the encoder seems more effective for a particular sample, it is a sign that the type of sample has been well thought of in the design of the codec, and is less likely to be an inaccurate approximation.

I think of ABR as just a more restricted form of VBR, based on the assumption that each person only has enough space on their DAP for one music file. The thing about vorbis is, the quality settings are pretty much target bitrates, just that the encoder is much more forgiving to itself, and allows itself to deviate much more from the target per file, as after an infinite number of files, the files will tend towards the target bitrate, due to the heterogenous nature of music which you meantioned. So actually, vorbis is trying to get towards a target bitrate, just in a cleverer way, as there will be a standard distribution of bitrates, with the mean being the target bitrate. So when it sounds like ABR, it is, just a lot cleverer, as the main aim of an encoder is to be more effective by decreasing the compression ratio for a given quality. So cutting back on the bitrate when possible is intrinsically part of VBR, not just ABR.

QUOTE (dv1989 @ Jun 10 2011, 01:30)

As have the VBR algorithms of all the leading audio codecs. Again, it has nothing to do with intrinsic deficiencies of lossy audio encoding. VBR just is logical given the heterogenous nature of most source material. It makes sense that end-users would prefer oscillating bitrate to disruptive changes in quality.

I know and agree.

I feel we're on the same page, you just misunderstood me.

Wow I've just realised how much I've written, I seem to be repeating myself a lot, maybe I should be some boring lecturer .

While your post is considered and doesnít look particularly unreasonable at a glance, Iím afraid this has gone beyond the level of thinking I put in. One of the many people here with a better understanding of audio encoding than me might try! (And announce my imminent extradition to Dunceís Island, maybe.)

I do accept that vbr is necessary, music does constantly change in complexity, I just think that with the current state of encoders, some peaks in bitrate may be a necessary evil due to the deficiencies (I'm getting sick of saying this) in the design.

When you say relatively few sine waves (surely that depends on the resolution?), isn't that more than only one that would be necessary if it were simply a sine wave? If there were a square wave mode or something it would surely require less bits than choosing to represent it with sine? Perhaps the square wave was the poor example, but I think you yourself may be able to offer some more potent ones.

When you say relatively few sine waves (surely that depends on the resolution?), isn't that more than only one that would be necessary if it were simply a sine wave? If there were a square wave mode or something it would surely require less bits than choosing to represent it with sine? Perhaps the square wave was the poor example, but I think you yourself may be able to offer some more potent ones.

How about sin functions, since thats what pretty much every codec uses.

I meant what kind of signal would represent a problem to encoders? Well rather than square waves, which you claim aren't (although I reckon you could decrease bitrate by representing it using a straight forward square wave function for example).

Maybe you could improve encoders by using techniques that don't just use sin?

@Xanikseo: While everything is representable by series of sine waves, only a square wave is representable by a square wave (that is, without applying a filter after that, which makes it more like a sine wave). Only chip music (i.e. music using/emulating old computer audio chips) could potentially benefit from that suggestion.Let's put another example: If i add to an encoder the possibility to encode the vowels using a model (in fact, that's what speech codecs do), first, i would need deconstruct the sound to separate the speech from the audio, and second, the model may be good for unaltered voice, but in music, that's not necessarily the case.

In the end, lossy encoding is always based on transmiting information about the signal instead of the signal itself. The transformation to sine wave series is just one such way. SBR and Parametric encoding is another way. Modeling (like in speech codecs) is another way. They can be combined, but the more you focus on a specific case, the less applicable it is to other cases (And you would have an increase of cpu, memory and disk usage of the encoder/decoder).

I believe you were trying to say that, to avoid the increase of bitrate needed for complexs parts of the signal, the encoder changed to another way to represent it, so that it could encode that part with fewer bits.This isn't something new, and in fact it is being done in many encoders. Temporal noise shaping, noise normalization,... those are just some tools used in specific situations to send information about the signal.

In this regard, the best encoder could be the one that could use all the tools available in all circumstances (Like, for example, aplying SBR to a part of the signal without being necesary to use it for all content above a specific frequency band), but that means the stream needs more information to inform when these tools are activated and deactivated, so it is only applicable on the higher end of the bitrate range.And the truth is that development has focused on the lower end (to add more channels, to be used with video... etc...)

@Xanikseo: While everything is representable by series of sine waves, only a square wave is representable by a square wave (that is, without applying a filter after that, which makes it more like a sine wave).

Since you can make a sin wav from sampled square waves, I disagree ;)

But you're right, it is silly to use square waves as your basis function when you can use sin waves and take advantage of all the math developed for harmonic analysis and discrete fourier transforms.

I never said that you should use a square waves as the basis function, but only when it would be appropriate, ie when it would reduce the bitrate. Unfortunately, square waves were a bad example, as they do not occur so often in music, but the idea is there - that there are samples that are very hard to approximate using sine waves. Yes there are many advantages to using sine waves, since it is an area of Mathematics that is very well covered. Perhaps we are starting to reach the boundaries in that area, and it is time to explore other ways of approximating signals which should be used when sine waves would be less effective.

By the way, it is not possible to produce a sine wave with square wave samples, as you would need an infinite amount of them to produce a perfectly smooth sine wave curve. The only reason sine waves are used in audio compression is because it is (mostly correctly) assumed that the smoothness of the sine curve was lost when the sample rate decreased from an infinitely high frequency to a meagre 44.1KHz (for example). Similarly, you can only reproduce a perfect square wave with an infinite sum of sine wave, which is why I suggested a square wave mode, but apparently square waves are not a common occurrence in music.

According to the most recent listening test for low bitrates, CELT performed the best. IIRC this is due to the fact that as little of the bitstream as possible is used for defining things like switching block sizes / encoding modes etc. This fits with what you were saying, Jaz, that the lower overhead is of an advantage at very low bitrates. Apparently this also causes the bitrate to be a sort-of restrained VBR, in that the bitrate does not jump suddenly, but changes gradually. It is interesting that CELT does so well, considering the amount of compromises that were involved in the design of the codec.

However I still feel more flexibility would result in lower overall bitrates in certain circumstances and less needs for jumps in bitrate. Perhaps a more flexible way of informing the decoder when to activate and deactivate each "encoding mode" is needed (are these sorts of things CBR?, as in, is there always the same amount of information given to the decoder per second about this? Perhaps this should also be VBR-ised. If one "encoding mode" was used for 10 seconds without changing, it would be pointless to keep telling the encoder every 100th of a second that it should keep using the same "encoding mode"!). This will probably result in a higher memory usage though...

I'm happy with Q65, which actually averages out to about 120 kbps in my collection.

Granted, I haven't tried Ogg Vorbis and can't speak for or against its quality, but AAC is a native codec to the iPod, and you won't have to muck around with alternate firmwares, etc. to get vorbis working.

(Edit: Whoops, didn't see that you gave your iPod away. Still, AAC is much more widely supported than ogg vorbis...)

I'm happy with Q65, which actually averages out to about 120 kbps in my collection.

Granted, I haven't tried Ogg Vorbis and can't speak for or against its quality, but AAC is a native codec to the iPod, and you won't have to muck around with alternate firmwares, etc. to get vorbis working.

(Edit: Whoops, didn't see that you gave your iPod away. Still, AAC is much more widely supported than ogg vorbis...)

Their are many devices that can play vorbis check out http://wiki.xiph.org/PortablePlayers and don't forget that the droids can play vorbis as well bye bye Iphone. Apples ipod firmware is a joke with rockbox on the Ipod you have so much more control over the sound of you're player with a full EQ no crappy presets. also you're ipod turns into a portable hdd that can be plugged and played with any pc and dose not need Itunes.