IPB

Welcome Guest ( Log In | Register )

 
Closed TopicStart new topic
Lame 3.94alpha6 testing thread.
JohnV
post Dec 9 2002, 07:26
Post #1





Group: Developer
Posts: 2797
Joined: 22-September 01
Member No.: 6



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 [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
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
Go to the top of the page
+Quote Post
JohnV
post Dec 9 2002, 08:00
Post #2





Group: Developer
Posts: 2797
Joined: 22-September 01
Member No.: 6



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 [x],2 which gives the best results. Although, like I explained above, the -X [x],2 should only affect short blocks.


--------------------
Juha Laaksonheimo
Go to the top of the page
+Quote Post
ErikS
post Dec 9 2002, 08:28
Post #3





Group: Members
Posts: 757
Joined: 8-October 01
Member No.: 247



OT: How can it be that it has more stop blocks than start blocks?
Go to the top of the page
+Quote Post
Gabriel
post Dec 9 2002, 08:36
Post #4


LAME developer


Group: Developer
Posts: 2950
Joined: 1-October 01
From: Nanterre, France
Member No.: 138



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)
Go to the top of the page
+Quote Post
mithrandir
post Dec 9 2002, 23:50
Post #5





Group: Members
Posts: 669
Joined: 15-January 02
From: SE Pennsylvania
Member No.: 1032



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
Go to the top of the page
+Quote Post
LordofStars
post Dec 10 2002, 03:24
Post #6





Group: Members
Posts: 353
Joined: 28-April 02
Member No.: 1894



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.
Go to the top of the page
+Quote Post
Gabriel
post Dec 10 2002, 09:58
Post #7


LAME developer


Group: Developer
Posts: 2950
Joined: 1-October 01
From: Nanterre, France
Member No.: 138



-X problem solved in alpha 7 (the short block quant_compare was always used)
Go to the top of the page
+Quote Post
john33
post Dec 10 2002, 14:03
Post #8


xcLame and OggDropXPd Developer


Group: Developer
Posts: 3760
Joined: 30-September 01
From: Bracknell, UK
Member No.: 111



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


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
mithrandir
post Dec 10 2002, 17:04
Post #9





Group: Members
Posts: 669
Joined: 15-January 02
From: SE Pennsylvania
Member No.: 1032



QUOTE (Gabriel @ Dec 10 2002 - 03:58 AM)
-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. dry.gif

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. blink.gif
Go to the top of the page
+Quote Post
JohnV
post Dec 10 2002, 18:57
Post #10





Group: Developer
Posts: 2797
Joined: 22-September 01
Member No.: 6



QUOTE (Gabriel @ Dec 10 2002 - 10:58 AM)
-X problem solved in alpha 7 (the short block quant_compare was always used)

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


--------------------
Juha Laaksonheimo
Go to the top of the page
+Quote Post

Closed TopicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 23rd October 2014 - 16:38