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: lame3100h, a functional extension (Read 45422 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

lame3100h, a functional extension

Reply #50
In my opinion, people who use your encoder  first of all care about quality and then speed. So if SSE2 causes some
precision loss then it might be worth to drop this optimization. Though it's quite strange that it causes such distortion  because untill now there is a common belief that different compilers shouldn't produce noticeable audible differences.

I get a miserable 6x speed (non-SSE2 3.100i) on my Atom based netbook with all 4 threads fully loaded  , but it's not an issue at all.

AFAIK, most LAME builds from Rarewares are SSE2-optimized, too (and because of that, these builds are very fast). The precision loss appears (most likely) because LAME 3.100 is in early alpha stage now. In my opinion, we'll need to wait for a stable LAME release.

lame3100h, a functional extension

Reply #51
Before publishing 3100i I will remove the SSE2 version because I am not able to do anything about it no matter what's the reason for the problem.

As for the non-SSE2 version which is about to go final:
My sensitivity for pre-echo stuff has improved a little bit, and based on eig I have tried to optimize the precision of the impulses so that I personally am rather happy with 3100i's behavior. I'm well aware though that this doesn't tell very much about audible quality for pre-echo sensitive people or maybe average Joe.
I'd welcome very much if somebody please could check if there can be improvement for critical stuff by using other values for --adbr_short (default: 510 kbps for -V1+ or better) and/or --adbr_start (default: 260 kbps for -V1+ or better).

Added: I forgot that maybe the --adbr-stop defaults (>= 380 kbps for -V1+ or better) might be a bit high for the case that a short/short frame is followed by a short/stop frame, because in this case the stop granule may eat up too much of the available data space so that the short granule before it does not get enough bits.
So trying a somewhat lower --adbr_stop value may be worth while too.
lame3995o -Q1.7 --lowpass 17

lame3100h, a functional extension

Reply #52
I consider the --adbr-stop behavior I mentioned a bug, because it's my strategy to favor short blocks in a situation of restricted available data space.
I corrected this, and you will get this behavior when downloading again. No need to test other --adbr_stop values (at least not for me) with this version.
I also deleted the troublesome SSE2 version.
lame3995o -Q1.7 --lowpass 17

lame3100h, a functional extension

Reply #53
I'm still not completely comfortable using an alpha version of Lame for anything beyond testing purposes. I do like what I've heard so far though. Is the last version of the 99.5 extension (I think it was 995f) considered stable enough for use?

lame3100h, a functional extension

Reply #54
Yes, 3.99.5f was the last 3.99.5 extension version. No stability issues were reported, all the younger versions were because of the arrival and good experience so far with 3.100a2, and due to further ripening concerning the extension.
lame3995o -Q1.7 --lowpass 17

lame3100h, a functional extension

Reply #55
I've done another small change to 3100i concerning behavior of frames of block type short/short in situations where the encoder is running out of data space. Should be a bit more appropriate now in certain situations. Available when downloading again.
lame3995o -Q1.7 --lowpass 17

lame3100h, a functional extension

Reply #56
I'll retest, because the result of the latest encoder is more interesting. Expect to take 150 days or so.
Encoders
LAME3100i(this encoder) V2+
http://dl.getdropbox.com/u/2681777/Lame3100i/lame3100i.zip
LAME 3.99.5 V1
http://www.rarewares.org/files/mp3/lame3.99.5.zip
LAME 3.98.4 CBR 224kbps -q 0

Helix MP3 Encoder(2005) -X2 -U2 -V146
http://www.rarewares.org/files/mp3/helix_mp3enc_CVS.zip
BladeEnc 0.94.2(low anchor)
http://www.softpedia.com/get/Multimedia/Au.../BladeEnc.shtml

Bitrates
encoders 25-samples albums
3100i  235.0  222.9
3.995  227.5  224.6
3.984  224.6  224.1
Helix  221.3  225.3
Blade  224.1  224.0


lame3100h, a functional extension

Reply #57
OK, so I publish the current 3100i as final in a new thread, as I have not heard of anybody currently doing a listening test and I have finished all my testing.
lame3995o -Q1.7 --lowpass 17

lame3100h, a functional extension

Reply #58
I started to test 3.99.5 V1 V0+, 320k as well as the funtional extension builds (3995f). Quality is pretty good with both but unfortunately some problems remain and some are pretty bad.

Emese: Very bad quality up to V1/ V1+ and still not too good at V0/V0+. No benefit from the + settings. Tested 3100i - improvement. V0+ is still a bit noisy.

Florida Seq : To me its way worse than EIG. At 5.0 secs the smearing is so severe. I abx V0/V0+ 10/10  without listening to the reference. The + settings provide no benefit here.  Edit: I tried again with 3100i: 7/10 then 10/10. I think there is an improvement but still a problem.

Angel falls 1st : Good progress with the + settings. Ringing is much reduced. + Settings have big impact here.

EIG: There is a click maybe around 3 secs easily heard @ V3 and V2. Much reduced at V1 / V0. Otherwise pretty good.

Catanets2_edit: 3.99.5 CBR modes abxable including 320k  10/10.. VBR is much better failed to abx V0

lame3100h, a functional extension

Reply #59
I started to test 3.99.5 V1 V0+, 320k as well as the funtional extension builds (3995f). Quality is pretty good with both but unfortunately some problems remain and some are pretty bad.

Did you use an ABC/HR software?

lame3100h, a functional extension

Reply #60
@shadowking:

Thank you very much for testing. Sounds like 3.100a2 and/or 3.100i are worth the development.
Sure there are samples that need highest quality settings or can't even be brought close to perfection with the highest settings.
I'll have a look at Emese and Florida Seq.
lame3995o -Q1.7 --lowpass 17

lame3100h, a functional extension

Reply #61
I tried again 1st thing this morning with fresh ears 3100i V0+

Florida: I didn't compare to 3.99.5 directly but have a strong feeling that 3100 is better (florida). Still easy to abx

foo_abx 1.3.4 report
foobar2000 v1.0.3
2013/02/26 11:37:50

File A: C:\stuff\music\abx\florida_seq.wav
File B: C:\stuff\music\florida_seq.mp3

11:37:50 : Test started.
11:38:10 : 01/01  50.0%
11:38:15 : 02/02  25.0%
11:38:24 : 03/03  12.5%
11:38:29 : 04/04  6.3%
11:38:34 : 05/05  3.1%
11:38:36 : 06/06  1.6%
11:38:40 : 07/07  0.8%
11:38:42 : 08/08  0.4%
11:38:45 : 09/09  0.2%
11:38:48 : 10/10  0.1%
11:39:55 : Test finished.

----------
Total: 10/10 (0.1%)


Emese:  Acidic noise  / distorsion


foo_abx 1.3.4 report
foobar2000 v1.0.3
2013/02/26 12:49:54

File A: C:\stuff\music\abx\emese.wav
File B: C:\stuff\music\emese.mp3

12:49:54 : Test started.
12:50:04 : 01/01  50.0%
12:50:06 : 02/02  25.0%
12:50:08 : 03/03  12.5%
12:50:10 : 04/04  6.3%
12:50:12 : 05/05  3.1%
12:50:13 : 06/06  1.6%
12:50:15 : 07/07  0.8%
12:50:16 : 08/08  0.4%
12:50:18 : 09/09  0.2%
12:50:20 : 10/10  0.1%
12:50:21 : Test finished.

----------
Total: 10/10 (0.1%)

lame3100h, a functional extension

Reply #62
Looks like emese is easier for you to ABX than florida_seq.
Can you say something about the difference 3100i -V0+ vs. 3.100alpha2 -V0 and CBR320?
lame3995o -Q1.7 --lowpass 17

lame3100h, a functional extension

Reply #63
I used 3100i -b320 :

Florida - To me CBR seems worse. There is more smearing .

foo_abx 1.3.4 report
foobar2000 v1.0.3
2013/02/26 22:18:44

File A: C:\stuff\music\abx\florida_seq.wav
File B: C:\stuff\music\florida_seq.mp3

22:18:44 : Test started.
22:19:00 : 00/01  100.0%
22:19:10 : 01/02  75.0%
22:19:20 : 02/03  50.0%
22:19:23 : 03/04  31.3%
22:19:25 : 04/05  18.8%
22:19:27 : 05/06  10.9%
22:19:41 : 06/07  6.3%
22:19:44 : 07/08  3.5%
22:19:48 : 08/09  2.0%
22:19:51 : 09/10  1.1%
22:19:53 : Test finished.

----------
Total: 9/10 (1.1%)


Emese: Same or maybe worse than VBR V0+.


foo_abx 1.3.4 report
foobar2000 v1.0.3
2013/02/26 22:16:03

File A: C:\stuff\music\abx\emese.wav
File B: C:\stuff\music\emese.mp3

22:16:03 : Test started.
22:16:24 : 01/01  50.0%
22:16:30 : 02/02  25.0%
22:16:31 : 03/03  12.5%
22:16:33 : 04/04  6.3%
22:16:35 : 05/05  3.1%
22:16:37 : 06/06  1.6%
22:16:39 : 07/07  0.8%
22:16:41 : 08/08  0.4%
22:16:42 : 09/09  0.2%
22:16:50 : 10/10  0.1%
22:16:52 : Test finished.

----------
Total: 10/10 (0.1%)


Florida 3100i standard -V0

foo_abx 1.3.4 report
foobar2000 v1.0.3
2013/02/26 22:38:33

File A: C:\stuff\music\abx\florida_seq.wav
File B: C:\stuff\music\florida_seq.mp3

22:38:33 : Test started.
22:38:49 : 01/01  50.0%
22:38:51 : 02/02  25.0%
22:39:00 : 03/03  12.5%
22:39:02 : 04/04  6.3%
22:39:04 : 05/05  3.1%
22:39:10 : 06/06  1.6%
22:39:12 : 07/07  0.8%
22:39:16 : 08/08  0.4%
22:39:18 : 09/09  0.2%
22:39:20 : 10/10  0.1%
22:39:24 : Test finished.

----------
Total: 10/10 (0.1%)


I think -V0+ is a bit harder to abx than -V0, but they are similar.

CBR 320 brute force approach cannot be counted on - at least for now. Its also fat , encodes silence @ 320, mono @ x2 the data rate. Its the most popular setting on P2P filesharing.  Maybe LAME at its current state has CBR issue.. But no developer since v3.90 has ever considered cbr320 or cbr in general it as a solution to anything. For some rare legacy device support it does ok @ 192..224 while still decent size for portables . In some rare cases it can outperform VBR but you cannot count on that as the norm at all.

lame3100h, a functional extension

Reply #64
Thank you for testing.

I 'e got a file 'A03_emese.flac' on my pc which contains a 6 sec. track, and I guess that's your emese sample.
I've encoded it, and it's clear that the '+' variant can't help here. It consists of short blocks to nearly 100 per cent, so that bit reservoir is nearly always close to empty. So the '+' variants can't provide extra bits for short blocks, and the data space available from 320 kbps frames isn't sufficient here. Quality isn't real bad though for my taste, but I must admit I can't concentrate well on such 'music' - and I'm not sensitive to pre-echo  (though I've 'improved' a bit).
While searching for the sample in the www, I've seen it's such a hard sample that even AAC at still higher bitrates can't get it right.

I don't have 'florida_seq' on my pc, and a www search couldn't find me it (the ff123net samples page is not available any more). Would you mind providing this sample?
lame3995o -Q1.7 --lowpass 17


lame3100h, a functional extension

Reply #66
Thank you for testing.

I 'e got a file 'A03_emese.flac' on my pc which contains a 6 sec. track, and I guess that's your emese sample.
I've encoded it, and it's clear that the '+' variant can't help here. It consists of short blocks to nearly 100 per cent, so that bit reservoir is nearly always close to empty. So the '+' variants can't provide extra bits for short blocks, and the data space available from 320 kbps frames isn't sufficient here.

Out of curiosity, how does 3.100 handle this sample at 640kbps freeformat?  (I'd check it myself but my ears are bad enough I can't hear most of the problems you're describing.)

 

lame3100h, a functional extension

Reply #67
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?
lame3995o -Q1.7 --lowpass 17