Yes, -V0 will usually be more efficient, as it wonít use 320 kbps frames where they are unnecessary.

It might also sometimes be of higher quality, if its different psychoacoustic model lends itself better to the source audio, or (if I understand correctly) if it can scavenge extra bits from the bit reservoir of subĖ320 kbps frames (however, [JAZ], in the former topic I linked, offers a hypothetical example of how the bit reservoir might work against quality).

-b320 is probably the safer bet in theoretical terms and for most use-cases; however, the likelihood of distinguishing MP3s at either setting from the source material is fairly low, so thereís only so much utility to perennial debates such as this one.

Please stop trying to decide between V0 and -b 320 based on quality. They are both as good as it gets in mp3, with only a tiny number of known tracks that are not transparent to both of them. The odds of you running into one of these exceptions is small, and even then, the artefacts are likely easy to miss, and the same artefact is often heard in both V0 and -b 320.

If -b 320 makes you "feel good" about your encodes then use it. The size savings of V0 won't make a big difference in this age of cheap storage.

The standard advice given out here is that even V0 is likely overkill, with V2 or even V4 or V5 being quite adequate for most people. The only time I would recommend using V0 is if, like myself, you don't have the time or patience to do your own ABX testing on your own equipment and music.

As for which -Vx level to use is a personal matter of taste.-V5 provides a quality which is perfect to most people for nearly all the tracks they listen to the usual way.-V2 or more so -V0 provides a safety margin for critical tracks which is appreciated by sceptical listeners.

With respect to today's storage capacities and prices many people can easily afford going even higher in bitrate than is done when using -V0.

V0's safety margin can be further improved by using the additional switches -b 320 -F. This provides maximum data space for encoding the audio data.

Without it -V0 can demand for audio data space to encode for the expected quality which can't be satisfied by the actual data space available.In this thread I showed that I found a track of regular pop music where V0's accuracy demands had to be reduced due to lacking data space for roughly 10% of the track. This isn't necessarily audible, but it's certainly nothing we should like. Using -b 320 -F improves the situation essentially, though at the expense of producing a 320 kbps data stream.This 320 kbps data stream isn't totally filled with audio data, and you can squeeze the air out of it by using Omion's fast and lossless mp3packer tool.

You can improve on -b 320 -F's effect by adding a lowpass like --lowpass 17.5 or similar, or by adding -Y.

Moreover Lame 3.98.4 has some switches --ns-bass/alto/treble to improve encoding quality for the bass/alto/treble region separately. As there is a little error in the implementation of these switches I created my own variant 3.98.4nwhich is totally identically to 3.98.4 with the exception of these switches which can be used now with full (and a bit extended) functionality. Moreover you can use it for finding out the amount of accuracy reductions.

The vital question of course is: are the improvements audible? Usually not, of course, simply because usually plain -V0 is perfect. In very critical situations however the improvements are audible. I care most about tonal problems, and for two of these problems I could ABX an improvement. /mnt is most sensitive to pre-echo problems, and he was able to prove the better quality for the one track he tested.

It's all about improving the safety margin, just a little step further than when going plain -V0.

As for the original question: I think it's nearly impossible to decide whether this solution is better than using CBR320 (as a funny side note: 'my' setting when not followed by mp3packer is a real CBR320 encoding created by the VBR mechanism, but it's of course not the CBR320 procedure the OP was talking about).

I personally beleive that this defensive VBR approach provides a better quality than CBR320 becausea) there has been evidence that CBR development has been neglected for quite a while. Lame development concentrated on VBR. b) CBR's and ABR's audio data production is less intelligent than VBR's. This can be an advantage, especially with high bitrate, when the more intelligent VBR mechanism has some serious weaknesses for certain kind of music. In contrary to prior versions Lame 3.98.4 has no such serious weaknesses IMO, that's why I think Lame 3.98.4's VBR mechanism used defensively with very high quality demands provides the better overall quality than CBR320 does.

-V0 -b 320 -F makes the VBR mechanism produce a real CBR320 stream. But my remark was just a side note, and I do recommend to use the fast and lossless mp3packer tool afterwards for an efficient encoding.As for 'my' other settings, I use --lowpass 16.7 as I don't need extreme HF and prefer Lame having more data space available for the (to me) more important frequency regions. As for the more defensive usage of - V0 I use my special Lame version with the additional options --ns-bass -9 --ns-alto -7.5 --ns-treble -6 --ns-short 1. With a setting like this you don't benefit very much from the mp3packer tool (the data stream consists to a large extent of audio data so there is little to kick off) so for getting a VBR generated CBR 320 file a setting like this is the way to go.

As for 'my' other settings, I use --lowpass 16.7 as I don't need extreme HF and prefer Lame having more data space available for the (to me) more important frequency regions. As for the more defensive usage of - V0 I use my special Lame version with the additional options --ns-bass -9 --ns-alto -7.5 --ns-treble -6 --ns-short 1.

I've tried the -V 0 -b 320 -F and then repacked with MP3packer, and as far as size and bitrate, it seems it is almost identical to just plain -V 0. I guess my goal is to generate a 320kbps file with the VBR mechanism, all of which are useful bits and won't repack to a lower bitrate. I tried out your modified LAME exe and messed around with the --ns-xxxx settings and it seems that when these are changed the -V 0 -b 320 -F+repack method is generating files that are a lot closer to true 320kbps. Would you mind explaining what these -ns-xxxx switches are actually doing? The documentation I found is pretty vague. Based on their name, it seems like they should be adjusted according to genre and listening preference. Is that true? Also, is using a LPF at 16.7 kHz really the best? Can't the presence of higher frequencies effect the sound of the lower (audible) frequencies?

A negative value of --ns-bass/-alto/-treble increases the signal-to-noise ratio for the lower/medium/higher frequencies thus making the encoding more defensive. I wouldn't try however to get extremely close to 320 kbps after mp3repacking as the situations become too frequent when the encoder runs out of data space and has to reduce accuracy.As for the lowpass you can try for yourself and use another value you prefer. Chance is pretty low however that you can hear a 16.7 kHz lowpass. Try to ABX it with high frequency heavy music.

Not exactly.-b 320 -F maximizes bitreservoir usage.With uncritical spots in music this means nothing, that's why average bitrate after mp3packing usually is close to using plain -V0. For critical spots however this can provide the data space required by -V0 which cannot be provided by plain -V0 resp. only by reducing encoding accuracy. See my first post in this thread for examples.

For a specific frame V0 quality demand may be satisfied by a say 224 kbps frame, and let's assume 80 bytes are left free as the bitreservoir for the nect frame. If the spot of the next frame is very demanding Lame will choose a 320 kbps frame and also use the 80 bytes from the bit reservoir. This may not be sufficient in extreme cases. If due to -b 320 -F the previous frame was encoded within a 320 kbps frame bit reservoir is significantly larger for the difficult frame.That's why -b 320 -F maximizes bit reservoir, that is the available data space for encoding the audio data generated by -V0.Sure situations are rare when this is an advantage.