Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Lame 3.94alpha6 testing thread. (Read 4112 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Lame 3.94alpha6 testing thread.

I just posted this to lame-dev mailing list:

Tested with Lame 3.94alpha6. Sample:
http://static.hydrogenaudio.org/extra/samp.../liebestod.flac
98.9% long blocks.

The problem is, that the bitrate and scalefac acts very weird with vbr nspsytune depending which noise measurement X-mode for short blocks is used. Basically depending on the short block X-mode, the bitrate and scalefac used is totally different with samples consisting mostly on long blocks. Clearly this can't be correct?

"Scalefac used" is from the Encspot, so I'm not totally sure if it's reliable.. should give some indication though.

-V4 --nspsytune -X 1,2:  (noise shaping type: 2)
Scalefac used: 10.7%
Average bitrate: 221.4 kbps
-----------------------------------------------------
-V4 --nspsytune -X 1,2 -Z: (noise shaping type: 1)
Scalefac used: 10.3%
Average bitrate: 222.0 kbps
-----------------------------------------------------
-V4 --nspsytune -X 1,4: (noise shaping type: 2)
Scalefac used: 55.9%
Average bitrate: 159.6 kbps
------------------------------------------------------
-V4 --nspsytune -X 1,4 -Z: (noise shaping type: 1)
Scalefac used: 2.5%
Average bitrate: 181.2 kbps
------------------------------------------------------

It's also weird that -X 1,4 -Z uses only 2.5% scalefac, but the bitrate is clearly lower than above -X 1,2 -Z settting which uses 10.3% scalefac, and all what is done is different X-mode for shortblocks. According to Wombat, some samples (consisting mostly of long blocks) sound good only when using -X
  • ,2 (-X2 for short blocks) and -Z has no effect on quality then.
    Must be a bug that changing noise measurement mode for short blocks has this kind of effect?

    All above settings for liebestod sample have these properties:
    Code: [Select]
    LR: 153 (45.54%)   MS: 183 (54.46%)
    block types   granules   percent
          long:       1330    98.958%
         start:          2     0.149%
         short:          8     0.595%
          stop:          4     0.298%
         mixed:          0     0.000%
Juha Laaksonheimo

Lame 3.94alpha6 testing thread.

Reply #1 –
Just to clarify for those who didn't know.
Liebestod has problems with nspsytune which can be heard for example with -V4 --nspsytune -X 1,4 or with APS.
-Z makes it better and also using -X
  • ,2 which gives the best results. Although, like I explained above, the -X
  • ,2 should only affect short blocks.
Juha Laaksonheimo

Lame 3.94alpha6 testing thread.

Reply #2 –
OT: How can it be that it has more stop blocks than start blocks?

Lame 3.94alpha6 testing thread.

Reply #3 –
stop/start issue: I asked the same thing yesterday.

The answer is: what you see is the number of granules.
As the stream is starting by a short block, you have 2 more stops than start (1 for each channel)

Lame 3.94alpha6 testing thread.

Reply #4 –
I think that noise measurement method #3 (-X 3) is "malfunctioning". If you select -X 3 or -X [n], 3 the bitrate increases too much compared with -X 0 or -X 1. Method #3 is always going to increase the bitrate but it seems to increase it too much in alpha6.

The two noise shaping methods (toggled by -Z) seem to deviate much more in terms of bitrate. Noise shaping method #2 acts rather like it did in the older alphas, but method #1 needs many more bits in alpha6.

These two anomolies help explain why APS bitrate has increased so much with the latest alpha. I believe APS uses -X 3 quite heavily.

As an aside, I've created the following commandline through much tweaking in order to produce a nice medium preset with alpha6. I'm not sure it is well-optimized with the older alphas, however.

-V3 --lowpass 17.5 --nspsytune --nssafejoint --nsmsfix 1.75 --ns-sfb21 5 --athaa-sensitivity -9 -X 1,0

Lame 3.94alpha6 testing thread.

Reply #5 –
I've noticed that abr and cbr 64 in alpha6 sound quite terrible while a max vbr bitrate of 64 is tolerable. It has a metallic ringing sound at higher frequencies but is fixed with a lower cutoff, like 16 instead of 24.
Lossy
r3mix zealot.

Lame 3.94alpha6 testing thread.

Reply #6 –
-X problem solved in alpha 7 (the short block quant_compare was always used)

Lame 3.94alpha6 testing thread.

Reply #7 –
Alpha 7 Win32 binaries (.exe & .dll) available here.

Lame 3.94alpha6 testing thread.

Reply #8 –
Quote
-X problem solved in alpha 7 (the short block quant_compare was always used)

Ah, that's helps explains things...and supports why you shouldn't monkey around too much with these alphas. 

Using -X 1,0 with alpha6 was interpretted as -X 0 even though the --verbose output reported otherwise. No wonder I couldn't pragmatically use -X 1,3...alpha6 was changing this to -X 3, which is a much different animal especially in the bitrate arena.

Anyway, this is good news because I'm sure I'll get better output from -X 1,3 or -X 1,4 than with -X 1,0 and I won't have to pay the huge bitrate price that alpha6 was falsely enacting.
 

Lame 3.94alpha6 testing thread.

Reply #9 –
Quote
-X problem solved in alpha 7 (the short block quant_compare was always used)

Good to hear that the bug was fixed.
I'll close this thread and start another thread about 3.94a7.
Juha Laaksonheimo