Hello Mark,
I see not much reason to disturb the current (<=3.85) way things were
scaled. (read down why)
MT> The goal is something like this:
MT> VBR_q compression like
MT> 0 5.0
MT> 1 6.0
MT> 3 8.0
MT> So -V6 is supposed to give, on average, 128kbs.
MT> -V0 is supposed to give, on average, 256kbs. This doesn't really
MT> make sense because you might as well just use 256kbs CBR, but this
MT> is because many people expect that -V0 should give the best possible
MT> quality. -V1 should be around 220kbs, and with another 20% reduction
MT> from jstereo, that is down to 180kbs.
The V1 using your "qadjust" uses much higher bitrates in JS mode. I
also aim at 170->210 kbit/s average with respectively easy and hard to
encode music. I have one song that averages >280kbit/s with the new
scale.
There is no real funded reason to get vbr averages this high I think.
* >210kbit/s averages you should opt for 256kbit/s cbr, because the
chances are then much higher to get better quality. Vbr (archival
quality) only makes sense, imo, around 185kbit/s average. Easy
pieces will go as low as 160 and very hard peak at 220.
The reason for this (refering to your Q/remark in the other post) is
that a simple 192kbit/s is simply _not_ good enough for archiving.
If you play those on a good soundcard+ HQ headphones or hifi you
will pick most music out. It is more than necesary sometimes for
some frames to go up to 256 and even 320, and if you choose 192,
your music quality constantly is not good enough.
offering people a vbr mode >=256 is giving them the illusion this Q
will surpass 256cbr imho, and not much use for that I think.
* I also find it non-logical to not-adapt the lowpass filter to the
new scale (if this makes it as default). I find it quite ridiculous
that with '-V3' on qadjust=-2.5 I get averages up to 229kbit/s on my
music, but the frequency is cut off?
who has use for this? imho, anyone willing to go for averages
bitrates >200kbit/s wants _perfect_ (* ... you know) music, and a
lowpass filter on -V3 is quite silly.
if someone chooses to accept files > 200kbit/s (hard to encode),
they expect full range audio, and no filters. The old -V1 had this
right. The new scale forces me to take -V3 (in order to produce some
responsible size), defaulting a lowpass filter.
[I am aware I can disable the filter, but the underlying
argument is the issue, not the fact I can hack some reasonable
result out of it]
* I, and many with me (these are the people that are willing to use
VBR) did many vbr listening tests, and are very content with the old
scale. I think there is not much reason to change the scale in the
drastical manner it happened with 3.86alpha.
I encourage, and would like to see it tweaked, the new vbr_mt,
because of the great speed advantage in vbr mode.
MT> All the various default settings (jstereo, lowpass filtering) are
MT> based on the compression ratio. For VBR, the compression ratio is not
MT> known in advance, so LAME uses the above table.
In short: Don't fix what isn't broken.
On my site (>30000 hits right now) I have had only 3 people mailing me that they found
some
disturbing artifacts in the "LAME -V1 -mj -h -b128" mode[<=3.85]. Two of them
were resolved with 3.83 (and 3.84-Z), and the one I cannot hear myself,
but I had to suggest 256cbr to solve the issue.
The old scale was ok imho, because I think there is not much
foundation to advice people to use vbr's averaging >256kbit/s. You
yourself have mentioned in the usage file that vbr is not advisable
for HQ work because of possible PSY errors etc, so I find it very
surprising to see the creation of the new scale.
>> Negative:
>> - some nasty artifacts in a file I encoded (every vbr_mt does
>> worse than vbr_rh on this file), I'll address this in another
>> thread. (*, if desired)
MT> yes, please send me the .wav files with a description of the
MT> problem. I have two samples already with artificts, but I
MT> haven't had a chance to figure out what is wrong.
I'm looking into this later this evening...
Roel, voting qadjust=.5 and -q1 for standard, so we can start finding
artifacts without the use for "-k" in a decent filesize rate.
--
Best regards,
Roel mailto:[EMAIL PROTECTED]
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
