lame3100h, a functional extension
Reply #67 – 2013-02-26 15:35:06
My ears probably aren't better. I am able to ABX emese and florida_seq at low bitrate, but not at -V0 nor -V0+. As for florida_seq: I guess it's about frame #188 ... #192, which contain all short block granules except for the last one. Bitreservoir is high at the time of frame #188 (~ 4000 bit) for both -V0 and -V0+. So no benefit again in this situation for the bitreservoir saving strategy of the functional extension. When using -V0+ frame #188 is encoded at full -V0 accuracy (even a bit better according to the high default --adbr_short value of 510 kbps), but this is done at the expense of a nearly empty bitreservoir after encoding frame #188. Standard Lame behaves different. It's strategy doesn't allow to use more than ~10000 bit for a frame. This means that frame #188 is encoded with a lower accuracy than the internal quality requirements demand for (bits used are ~20 per cent below that of -V0+), but it keeps bitreservoir at ~2000 bit which is in favor of the following frames. Due to lacking data space frames #189 to #192 are all encoded below Lame's internal accuracy demands no matter -V0 or -V0+, but because of the bigger bitreservoir in the case of standard Lame -V0 uses ~10 per cent more bits on frame #189, and ~5 per cent more bits on frame #190. Bits used for frame #191 and 192 are roughly the same for -V0 and -V0+. Because of the different bit allocation strategies -V0 can sound better than -V0+ on occasion. I prefer the -V0+ strategy because it is always better in the case of a sequence of only one or two short block granules (quite common with 'natural' music). Also in longer short block granule sequences I think it is better to throw all the bits needed at the first and second short block granules and accepting a somewhat lower accuracy for the third short block granule and also for the fourth. Just a belief though. Lame's standard strategy can be approximated a bit by using -V0.5+ or similar together with --adbr_short 400 or similar because bits used are restricted this way for the short block granules thus preserving more bits from the bitreservoir for the following frames. Limiting the accuracy increase of 3100i by using --snrincmax_short 3.0 or similar for the highest quality settings can help as well to approximate the standard behavior. Maybe it's a good idea to lower the default value of 510 kbps for short block granules, and/or use --snrincmax_short in a restrictive way. Has somebody a sample where a lower --adbr_short value and/or a small --snrincmax_short value results in an improved quality?