lossyWAV 1.2.0 Development Thread

Topic: lossyWAV 1.2.0 Development Thread (Read 311257 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.

lossyWAV 1.2.0 Development Thread

Reply #375 – 2009-04-16 07:35:48

Using --underlap 5 (I fixed the check in the parameter processing and it will now accept up to the advertised

will increase the processing time dramatically - using 2 would be a compromise (for one thing, it adds a central 1024 sample FFT analysis in addition to the two existing per codec-block). I prefer using --analyses 5 to add different FFT lengths into the calculation. My preference for --sortspread is 3 as it is weighted more to the first (i.e. lowest) result in the sorted FFT_Result array.

I haven't had time to examine the cause of the click in Therion - I feel that it may be something underlying in the lossless version which is exacerbated during the bit-removal process.

lossyWAV 1.2.0 Development Thread

Reply #376 – 2009-04-16 16:37:42

Unfortunately I can't help out with testing of these new settings as my hearing/listening situation don't allow me to pick up any problems. However, would it be a good idea to test the new settings with some other material? I realise that these are problem pieces but if transparency were achieved with other pieces surely that would prove their usefulness

lossyWAV 1.2.0 Development Thread

Reply #377 – 2009-04-16 22:48:40

For me what you're asking for is non-sense, on average music lossywav is transparent at much lower than -P, if you try to ABX this you will get useless 50% random guessing results which will not help improving the codec in any way. Yes, lossywav need more ABXable problem samples in its test database for safety. Therion & Abfahrt Hinwil are the only samples I know that can be used to tune lossywav near its transparency point. Adding popular song X by artist Y that is transparent on -q 0.5 is completely useless for testing if we know that other samples test fail at -q 1.5. Who cares if you're a Metallica fan & the complete Metallica discography is transparent at lossywav -q 0.5 for you, if lossywav fails to bring transparency on Therion & Abfahrt at -q 1.5 for me, it fails overall up to -q 1.5, that's all.
If you know new problem samples for lossywav at -q 1.5 (or -q 1) just post them, otherwise you'd better stay out of it.

For exemple Roberto's listening test Multiformat at 128kbps shows that on average music most people are happy with aotuv -q4, but if you know about the block switching issue it is obvious that -q4 fails on many samples Multi-Codec Listening Test. What does that means ? For me, it means that testing codec on average music with average users leads you to average conclusion. If you let other people decide for yourself then you can happily use MP3 at 128KBps, 95% user will find that it sound very good if don't specifically point them to listen to audio artefact. The average Joe doesn't know what to listen to, so he doesn't know how to criticize audio quality. If you only read Roberto's listening test then the block switching issue doesn't exist & aotuv is near perfect. Maybe there was a guy within the testers who was able to tell where it fails but if 99% of other guy tells that there is no problem, then the problem doesn't exist. Prey you're not one of those able to ABX the artefact without knowing it, because if it happens to you & you discover it , you're good to delete your whole collection, I already deleted my lossy backup several time before switching to 100% lossless & stop trusting anyone else but me.

Like it or not the only way to test lossy audio codec is through problem samples, ... but before you can even start listening to the problem cases, you have to actually find them. So your proposal to test lossywav on average music is non-sense & a pure waste on time. You can test lossywav on average music to find possible problem samples, you cannot test lossywav on average music to judge its quality.

lossyWAV 1.2.0 Development Thread

Reply #378 – 2009-04-17 11:08:32

I just tested --underlap 2 vs --underlap 8, --underlap 8 is always better & ABXable.

Code: [Select]

foo_abx 1.3.3 report
foobar2000 v0.9.6.4
2009/04/17 11:26:04

File A: C:\00- Therion (Artefact+Context) V1.1.3j -Q 0 --underlap 2.lossy.flac
File B: C:\00- Therion (Artefact+Context) V1.1.3j -Q 0 --underlap 8.lossy.flac

11:26:04 : Test started.
11:26:27 : 01/01  50.0%
11:26:53 : 02/02  25.0%
11:27:15 : 03/03  12.5%
11:27:48 : 04/04  6.3%
11:28:22 : 05/05  3.1%
11:28:44 : 06/06  1.6%
11:29:06 : 07/07  0.8%
11:29:25 : 08/08  0.4%
11:29:27 : Test finished.

 ---------- 
Total: 8/8 (0.4%)

Code: [Select]

foo_abx 1.3.3 report
foobar2000 v0.9.6.4
2009/04/17 11:29:42

File A: C:\01- Abfahrt Hinwil (Artefact Only) V1.1.3j -Q 0 --underlap 2.lossy.flac
File B: C:\01- Abfahrt Hinwil (Artefact Only) V1.1.3j -Q 0 --underlap 8.lossy.flac

11:29:42 : Test started.
11:29:55 : 01/01  50.0%
11:30:05 : 02/02  25.0%
11:30:15 : 03/03  12.5%
11:30:22 : 04/04  6.3%
11:30:31 : 05/05  3.1%
11:30:42 : 06/06  1.6%
11:30:50 : 07/07  0.8%
11:30:58 : 08/08  0.4%
11:30:59 : Test finished.

 ---------- 
Total: 8/8 (0.4%)

Then I tested -Q 0 --underlap 2 Vs. -Q 0.5 in order to see if --underlap 2 was better or worse than --underlap 5 (which I previously tested & is near to a 0.5 gain in the scale), first I add some trouble catching a difference but then I catched something & then it was a 100% success so I went up to 20 trials to erease the first failures. It was even easier on Abfahrt Hinwil which was a 8/8 from the start. The conclusion is --underlap 2 is worst than a 0.5 increase in the scale. --underlap is a time greedy parameter but it does improve quality in a very scalable way:

--underlap 2 < --underlap 5 (+0.5 increase in the scale) < --underlap 8, but --underlap 8 is very slow.

Code: [Select]

foo_abx 1.3.3 report
foobar2000 v0.9.6.4
2009/04/17 11:33:05

File A: C:\11- Lossywav Test\00- Therion (Artefact+Context) V1.1.3j -Q 0 --underlap 2.lossy.flac
File B: C:\11- Lossywav Test\00- Therion (Artefact+Context) V1.1.3j -Q 0.5.lossy.flac

11:33:05 : Test started.
11:33:39 : 00/01  100.0%
11:36:06 : 01/02  75.0%
11:36:27 : 02/03  50.0%
11:37:32 : 02/04  68.8%
11:38:06 : 02/05  81.3%
11:38:56 : 03/06  65.6%
11:39:13 : 04/07  50.0%
11:39:26 : 05/08  36.3%
11:39:37 : 06/09  25.4%
11:39:49 : 07/10  17.2%
11:40:02 : 08/11  11.3%
11:40:14 : 09/12  7.3%
11:40:26 : 10/13  4.6%
11:40:33 : 11/14  2.9%
11:40:47 : 12/15  1.8%
11:41:06 : 13/16  1.1%
11:41:19 : 14/17  0.6%
11:41:34 : 15/18  0.4%
11:42:02 : 16/19  0.2%
11:42:32 : 17/20  0.1%
11:42:37 : Test finished.

 ---------- 
Total: 17/20 (0.1%)

Code: [Select]

foo_abx 1.3.3 report
foobar2000 v0.9.6.4
2009/04/17 11:44:12

File A: C:\01- Abfahrt Hinwil (Artefact Only) V1.1.3j -Q 0 --underlap 2.lossy.flac
File B: C:\01- Abfahrt Hinwil (Artefact Only) V1.1.3j -Q 0.5.lossy.flac

11:44:12 : Test started.
11:44:57 : 01/01  50.0%
11:45:17 : 02/02  25.0%
11:45:37 : 03/03  12.5%
11:45:56 : 04/04  6.3%
11:46:11 : 05/05  3.1%
11:46:29 : 06/06  1.6%
11:46:49 : 07/07  0.8%
11:47:07 : 08/08  0.4%
11:47:09 : Test finished.

 ---------- 
Total: 8/8 (0.4%)

I tried too ABX -q 0 --sortspread 3 Vs. -q 0 --sortspread 7, but I failed, it seems --sortspread is not as scalable as --underlap. Unlike --underlap it seems --sortspread is a flat ~0.5 quality increase in the scale that doesn't improve much if you increase the parameter.

It remains to be tested for transparency but IMHO swallowing (-q 1.5 --sortspread 3 --analyses 5) or (-q 2 --sortspread 3 --analyses 5) as the new -portable might be a good start if --underlap is too CPU greedy. (-q 2 --sortspread 3 --analyses 5) is for almost sure already transparent with no drawback ... in fact all that remains to be tested is how far (-q 1.5 --sortspread 3 --analyses 5) is from being transparent. Also what is the min/max for --analyses, I know from --help the default is 2 but is there any logic behind 5 analyses instead of more or less, do you have a preference for --analyses ? Is 5 random ?

lossyWAV 1.2.0 Development Thread

Reply #379 – 2009-04-17 11:49:00

The 2 default FTT analyses are 64 samples and 1024 samples (1.45msec and 23.2msec for 44.1kHz). --impulse adds a 32 sample FFT for impulse detection (0.725msec). What --analyses 5 does is add 128, 256 and 512 sample FFT analyses into the calculation.

lossyWAV 1.2.0 Development Thread

Reply #380 – 2009-04-17 12:06:54

I tested V1.1.3j -Q 1.5 --sortspread 3 for transparency, it is not transparent but it's medium/hard to ABX & artefact are very low. It doesn't sound bad at all. It might be transparent with the help of --underlap 2 or --analyses 5.
Just tell me if swallowing --underlap 2 is possible or not. --analyses 5 alone might help but alone it seems a little weak IMHO.

It's either you swallow -q 1.5 --sortspread 3 --underlap 2 --analyses 5 as the new -portable (but without --underlap 2 the safety margin will be too low IMHO)
or you only swallow -q 2 --sortspread 3 --analyses 5 as the new -portable (in fact -q 2 --sortspread 3 is most likely already transparent & --analyses 5 only adds a bigger safety margin here)

another solution is -q 1.75 --sortspread 3 --analyses 5 as the new -portable, the advantage is that you left --underlap 2 out, but you still gain some more Kbps.

--sortspread 3 is strong (~0.5 gain) but both --underlap 2 & --analyses 5 are weaker (~0.25 gain each) & --underlap 2 is slower. --underlap has a major speed drawback but it can be just as strong as --sortspread if you are ready to sacrifice encoding speed. It's lossy & you only encode once.

Code: [Select]

foo_abx 1.3.3 report
foobar2000 v0.9.6.4
2009/04/17 12:50:07

File A: C:\11- Lossywav Test\00- Therion (Artefact+Context) Lossless.flac
File B: C:\11- Lossywav Test\00- Therion (Artefact+Context) V1.1.3j -Q 1.5 --sortspread 3.lossy.flac

12:50:07 : Test started.
12:50:25 : 01/01  50.0%
12:50:41 : 02/02  25.0%
12:50:52 : 03/03  12.5%
12:51:21 : 04/04  6.3%
12:52:27 : 05/05  3.1%
12:53:00 : 06/06  1.6%
12:53:53 : 07/07  0.8%
12:54:41 : 08/08  0.4%
12:54:42 : Test finished.

 ---------- 
Total: 8/8 (0.4%)

Code: [Select]

foo_abx 1.3.3 report
foobar2000 v0.9.6.4
2009/04/17 12:55:12

File A: C:\01- Abfahrt Hinwil (Artefact Only) Lossless.flac
File B: C:\01- Abfahrt Hinwil (Artefact Only) V1.1.3j -Q 1.5 --sortspread 3.lossy.flac

12:55:12 : Test started.
12:55:29 : 01/01  50.0%
12:55:50 : 02/02  25.0%
12:56:12 : 03/03  12.5%
12:56:30 : 04/04  6.3%
12:57:21 : 05/05  3.1%
12:57:51 : 06/06  1.6%
12:58:27 : 07/07  0.8%
12:59:16 : 07/08  3.5%
12:59:18 : Test finished.

 ---------- 
Total: 7/8 (3.5%)

lossyWAV 1.2.0 Development Thread

Reply #381 – 2009-04-17 13:30:37

I think that over the weekend I will process my 55 problem sample set using a number of different settings to determine which give the best improvement (determined by your existing ABX'ing) for the lowest increase in bitrate (determined by these tests). In this way we should be able to determine which are the best combination(s).

I think that users should be able to "slow down" the calculation speed by increasing the underlap - I would be prepared to accept --underlap 2 as a default value (with 1 available as a user selection). Similarly, maybe --analyses 5 is a desirable default, again with user options to use 2 to 4 analyses. I am reluctant to reduce the processing rate too much, however, if better quality can be achieved at the same bitrate but just a bit slower then that is a desirable result.

lossyWAV 1.2.0 Development Thread

Reply #382 – 2009-04-17 13:41:30

I quickly tested the impact of the various new parameters on a real album just to have an idea. I didn't run the encode untill the end, I only took the estimated time after 30sec of encoding:

-q 2 4min
-q 2 --sortspread 3 4min 18 sec
-q 2 --underlap 2 5min 44 sec
-q 2 --analyses 5 6min 37 sec

It seems --analyses 5 has a bigger impact on speed than --underlap 2 for a comparable gain in the scale. (previously I thought --underlap 2 was worst)

--sortspread 3 is ok but adding both --underlap 2 & --analyses 5 at the same time will have a major impact on encoding time, it might be something like X2 slower. (4min+1min44+2min37)

I should test --underlap 2 Vs. --analyses 5 to see what is best qualitywise, but if you take speed in consideration then -q 1.75 --sortspread 3 --underlap 2 (WITHOUT --analyses 5) might very well be the best compromise between speed/quality/size. At first look that's my personnal favorite. So far I didn't realized --analyses 5 & --underlap 2 were so slow, --sortspread 3 is much much stronger as a new parameter, not only it sounds better, but it's much faster. I am wondering if a 0.25 quality gain is worth the speed cost for both --analyses 5 & --underlap 2, a new noise shaping method might be a much better option Maybe just swallowing -q 2 --sortspread 3 as the new -portable is the best option afterall, it's a flat 0.5 gain in the scale without any real speed drawback, without the headache of ABXing minor 0.25 gain in the scale. It seems a little strange to me to swallow --underlap 2 & left out --analyses 5, when both are so close.

I dunno ... I like the quality gain, but I don't like the speed drawback personnaly.

lossyWAV 1.2.0 Development Thread

Reply #383 – 2009-04-17 14:26:04

A quick test using one album:

Code: [Select]

|---------------------------------------------------------|
| -q 2 | -X 3 | -U 2 | -a 5 |  Time  |  Bitrate  |Increase|
|------+------+------+------+--------+-----------+--------|
|   X  |      |      |      |  51.32 | 394.8kbps | ------ |
|   X  |   X  |      |      |  66.31 | 414.1kbps | +4.89% |
|   X  |      |   X  |      |  84.32 | 406.6kbps | +3.00% |
|   X  |      |      |   X  |  99.43 | 415.2kbps | +5.17% |
|   X  |   X  |   X  |      | 112.56 | 424.2kbps | +7.44% |
|   X  |   X  |      |   X  | 136.81 | 425.0kbps | +7.64% |
|   X  |      |   X  |   X  | 179.03 | 428.4kbps | +8.51% |
|   X  |   X  |   X  |   X  | 247.19 | 435.0kbps |+10.19% |
|---------------------------------------------------------|

lossyWAV 1.2.0 Development Thread

Reply #384 – 2009-04-17 15:17:31

As -U is very scalable it might be more interesting to increase -U rather than using -a 5 at all.

It might be interesting to add -U 3-8 to your table, so that we know what -U (Number) alone encode as slow as -U 2 -a 5 together, then I could ABX both to see if it's not more interesting to increase -U alone than using -a 5 at all. Maybe it's not worth at all, but it remains to be tested.

I know you previously said you prefer -a 5 over - U 2, but speed test shows the exact opposite & -U 2 has the advantage of being scalable.

Personnaly I prefer - U 2 over -a 5, because it's faster for the same quality gain. So following some logic, - U 3 (or maybe - U 4, I have no clue) should be better qualitywise for the same speed.

- U 2 -a 5 is very time greedy (179.03), I am confident that - U 3 (or - U (Number) ) alone will be faster for an almost comparable quality gain because from - U 2 (84.32) to - U 2 -a 5 (179.03) the margin is big for a -U (number) in between to swallow the quality gain of -a 5 without being as slow.

lossyWAV 1.2.0 Development Thread

Reply #385 – 2009-04-17 16:12:04

I think this is getting a bit too empirical! Well, for me to contribute anyway. So I'll add this intead...

With --underlap, you know exactly what it's doing - with the default settings, there's a moment between two adjacent analyses which is 6dB down from the centre of each - that's the hanning window function. --underlap 2 changes this to only 1.4dB down.

It's a little over simplistic, but basically that sets the maximum magnitude of reduction you could get in the added noise with --underlap 2: 4.6dB. Mostly you won't get anything like this, but you should never get any more - i.e. it can never give a greater improvement that this.

Remember that lossyWAV adds noise in 6dB increments - that's what "one bit" is. Underlap 2, at its most generous, is never as generous as keeping one extra bit overall - at most it'll keep 1 extra bit sometimes. Given the 6dB resolution of the final process, it seems a bit mad going for an underlap greater than 2 because you're getting seriously diminishing returns.

e.g. from underlap 2 to underlap 3, the improvement is less than 1dB. Given the 6dB step size, I think this is silly - unless you can prove that it's the less than 1dB "error" in this domain that's the cause of occasional audible problems.

With --analyses x, you're adding more time/frequency resolution stages. This could be a good thing. I can't think of an easy way of predicting the min/max improvement it can bring: it's dependent on the signal and spreading functions. On specific signals, it could force down the added noise dramatically at specific moments. If perceptually relevant, this is highly useful. It's unlikely to force the added noise down across the board (good, because there isn't a problem across the board!) - because most signal dips are already being correctly caught by two analyses.

Cheers,
David.

lossyWAV 1.2.0 Development Thread

Reply #386 – 2009-04-17 16:32:13

I don't understand all this theoric stuff, but from what I understund this sentence: "it seems a bit mad going for an underlap greater than 2 because you're getting seriously diminishing returns." is wrong I can ABX --underlap 2 from --underlap 5 & --underlap 2 from --underlap 8. Not only I can ABX it but it is not very hard to ABX. So despite all this theoric knowledge there is a gain in real listening test.

Also, Quote: "I think this is silly" ... again sorry but I am 100% sure of what I hear. The "diminishing returns" of --underlap are not as small as you think. --underlap may have its wall, I am not sure I can ABX --underlap 5 vs. --underlap 8, I never tried, but --underlap 2 is not the upper limit of --underlap at all, that is 100% sure. I have no explanation for it, there might be holes in your theoric knowledge, I dunno. All I know is what I hear.

lossyWAV 1.2.0 Development Thread

Reply #387 – 2009-04-17 16:50:50

Just tried --underlap 2 vs. --underlap 4, this should remove you any doubt about --underlap 2 not being the upper limit of --underlap.

Code: [Select]

foo_abx 1.3.3 report
foobar2000 v0.9.6.4
2009/04/17 17:47:02

File A: C:\00- Therion (Artefact+Context) V1.1.3j -Q 0 --underlap 2.lossy.flac
File B: C:\00- Therion (Artefact+Context) V1.1.3j -Q 0 --underlap 4.lossy.flac

17:47:02 : Test started.
17:47:17 : 01/01  50.0%
17:47:32 : 02/02  25.0%
17:47:51 : 03/03  12.5%
17:48:20 : 04/04  6.3%
17:48:39 : 05/05  3.1%
17:49:01 : 06/06  1.6%
17:49:23 : 07/07  0.8%
17:49:43 : 08/08  0.4%
17:49:45 : Test finished.

 ---------- 
Total: 8/8 (0.4%)

lossyWAV 1.2.0 Development Thread

Reply #388 – 2009-04-17 17:55:33

@sauvage78,

I'm not trying to argue against what you hear - far from it - that's far more important than what I think!

My understanding of how it probably works might not be consistent will all the tunings Nick has added, or the way it's really implemented. It's strange it makes a huge difference, but I'm sure there's an explanation.

I think it's worth investigating what's happening in this specific sample.

Cheers,
David.

lossyWAV 1.2.0 Development Thread

Reply #389 – 2009-04-17 17:56:29

Quote from: sauvage78 on 2009-04-16 22:48:40

For me what you're asking for is non-sense, on average music lossywav is transparent at much lower than -P, if you try to ABX this you will get useless 50% random guessing results which will not help improving the codec in any way. Yes, lossywav need more ABXable problem samples in its test database for safety. Therion & Abfahrt Hinwil are the only samples I know that can be used to tune lossywav near its transparency point. Adding popular song X by artist Y that is transparent on -q 0.5 is completely useless for testing if we know that other samples test fail at -q 1.5. Who cares if you're a Metallica fan & the complete Metallica discography is transparent at lossywav -q 0.5 for you, if lossywav fails to bring transparency on Therion & Abfahrt at -q 1.5 for me, it fails overall up to -q 1.5, that's all.
If you know new problem samples for lossywav at -q 1.5 (or -q 1) just post them, otherwise you'd better stay out of it.

For exemple Roberto's listening test Multiformat at 128kbps shows that on average music most people are happy with aotuv -q4, but if you know about the block switching issue it is obvious that -q4 fails on many samples Multi-Codec Listening Test. What does that means ? For me, it means that testing codec on average music with average users leads you to average conclusion. If you let other people decide for yourself then you can happily use MP3 at 128KBps, 95% user will find that it sound very good if don't specifically point them to listen to audio artefact. The average Joe doesn't know what to listen to, so he doesn't know how to criticize audio quality. If you only read Roberto's listening test then the block switching issue doesn't exist & aotuv is near perfect. Maybe there was a guy within the testers who was able to tell where it fails but if 99% of other guy tells that there is no problem, then the problem doesn't exist. Prey you're not one of those able to ABX the artefact without knowing it, because if it happens to you & you discover it , you're good to delete your whole collection, I already deleted my lossy backup several time before switching to 100% lossless & stop trusting anyone else but me.

Like it or not the only way to test lossy audio codec is through problem samples, ... but before you can even start listening to the problem cases, you have to actually find them. So your proposal to test lossywav on average music is non-sense & a pure waste on time. You can test lossywav on average music to find possible problem samples, you cannot test lossywav on average music to judge its quality.

Well, I suggested "other pieces" not "average music". Sorry for trying to help. If everybody's happy to try to tune Lossywav on 2 samples that's fine with me

lossyWAV 1.2.0 Development Thread

Reply #390 – 2009-04-17 18:30:28

botface:
The problem is that there is no other pieces easyly ABXable at -q 1.5 that we are aware of, hopefully tuning this 2 samples will help tuning lossywav on all music. Everything is tied, it's not as if every sample would be separated from the rest of the music. So far each parameter that affects one of the 2 samples affect the second in the same way (good or bad) & so far it never happen that improving the quality on this 2 samples would decrease the quality of lossywav on the rest of the music, this is not random. I am not completely nuts listening endlessly to the same 2 samples ... well not yet I hope but I may become

lossyWAV 1.2.0 Development Thread

Reply #391 – 2009-04-17 20:18:29

Quote from: sauvage78 on 2009-04-17 18:30:28

botface:
So far each parameter that affects one of the 2 samples affect the second in the same way (good or bad) & so far it never happen that improving the quality on this 2 samples would decrease the quality of lossywav on the rest of the music,....

OK. My concern was that in concentrating on these two samples adverse effects could paerhaps be introduced that may affect other samples that had been OK up to now. I didn't realise you were checking other samples for regression too.

lossyWAV 1.2.0 Development Thread

Reply #392 – 2009-04-18 03:32:21

I just tried to encode an album 3 times in order to compare the final filesize:

204 Mo (214 186 464 octets) -q 2.5
200 Mo (210 518 460 octets) -q 2 --sortspread 3
204 Mo (214 348 111 octets) -q 2 --analyses 5

The conclusion of this is:
--analyses 5 completely not worth it, it is slow & produce file of similar size than a 0.5 increase in the scale while bringing only a quality improvement of 0.25.
--sortspread 3 is completely worth it, it is not much slower & produce smaller size than a 0.5 increase in the scale while bringing a quality improvement slightly superior to 0.5

--underlap 2 is somewhere in between, it is faster/smaller/better than --analyses 5, but not as good as --sortspread 3. It is a trade between quality & speed, with a medium size increase.
It is not absolutely worth it, but not absolutely worthless at the same time. So I think this should be left out for now but remembered as a possible option.

IMHO --analyses 5 must be forgotten, --underlap must be tested further & --sortspread 3 must be immediatly swallowed.

If this is confirmed by your encoding test, plz adopt --sortspread 3 as default & -q 2 --sortspread 3 as the new -portable & make a release.

The overall conclusion of this is that halb27 was right, a new parameter that increase the quality must be tested for speed & outputed filesize before making any conclusion, at first look --analyses 5 looked promising on problem samples, but on real life encoding it worth nothing.

Note: I think I am done with lossywav testing for some time now, real life is calling me.

lossyWAV 1.2.0 Development Thread

Reply #393 – 2009-04-18 08:58:07

Both --analyses 5 and underlap 2 add extra FFT analyses. As both increase the bitrate / reduce the bits-removed for a given file / quality level combination it is inferred that they are both finding low points in the noise floor which are not found when they are not used.

I will get to the comparative analysis later today - it may indeed be that we end up with a revised --portable using --quality 2 --sortspread 3.

lossyWAV 1.2.0 Development Thread

Reply #394 – 2009-04-18 21:11:16

Quote from: sauvage78 on 2009-04-18 03:32:21

IMHO --analyses 5 must be forgotten, --underlap must be tested further & --sortspread 3 must be immediatly swallowed.

If this is confirmed by your encoding test, plz adopt --sortspread 3 as default & -q 2 --sortspread 3 as the new -portable & make a release.

First, thanks for the testing you did. Second, I like to remind that these conclusion would hold for qualities around -q 2 (I guess +/- 1). Should --standard become -q 4.5 --underlap 3, or is it better (and faster) at -q 5 (without -U)?
Perhaps we can never tell?

Quote from: Nick.C on 2009-04-18 08:58:07

Both --analyses 5 and underlap 2 add extra FFT analyses. As both increase the bitrate / reduce the bits-removed for a given file / quality level combination it is inferred that they are both finding low points in the noise floor which are not found when they are not used.

yes, that is confirmed by your test table. Wouldn't that mean the thresholds should be adjusted too? (I'm asking just in general)

lossyWAV 1.2.0 Development Thread

Reply #395 – 2009-04-18 21:28:57

I think that the main problem we have is that there are a large number of parameters to be balanced - some of which are not user selectable, i.e. skew, noise-threshold-shift and signal-to-noise-ratio.

My gut feeling is that --underlap 2 is a worthwhile addition to the default settings, as is --sortspread 3 (from the much appreciated testing by sauvage78!).

Bitrate creep (upward) has set in - but, if as has been suggested, we can always tweak the presets downward (i.e. maybe --portable maps to -q 2.1 not -q 2.5; etc.).

I think that I should remap the noise-threshold-shifts so that --sortspread 3 output is bitrate matched to default spreading for each of the 10 permanent quality levels (as I did for the (now old) --sortspread parameter).

I will carry out this and revert --sortspread to a switch rather than taking a parameter - this with a view to final round of testing before (if) --sortspread becomes the default spreading and the existing default spreading function is removed.

lossyWAV 1.2.0 Development Thread

Reply #396 – 2009-04-19 06:56:56

I fear that -q 2 --sortspread 3 is not fully transparent, this is very dispointing, below is logs from -q 2 --sortspread 3 Vs. lossless & -q 2.5 Vs. lossless. -q 2 --sortspread 3 Vs. lossless is not a full success but it is not like -q 2.5 Vs. lossless a full failure, worse it's closer to be a success than to be a failure. -q 2 --sortspread 3 is hard to ABX & artefact are very light, it sounds good, but I would lie if I would tell that I think it is transparent. After all this tests this is quite discouraging. We are very near to transparency but not there yet & if we increase the bitrate then --sortspread 3 might become useless I dunno what to think ... I think that the explanation to this is diminishing returns, near -q 0 --sortspread 3 there is a big boost of ~0.5 in the scale, but the closer you get to -q 2.5, the slimest is the gain. All logic would have been that -q 2 --sortspread 3 would have been transparent but it is not. Sadly it is slightly below.

Code: [Select]

foo_abx 1.3.3 report
foobar2000 v0.9.6.4
2009/04/19 07:23:34

File A: C:\11- Lossywav Test\00- Therion (Artefact+Context) Lossless.flac
File B: C:\11- Lossywav Test\00- Therion (Artefact+Context) V1.1.3j -Q 2 --sortspread 3.lossy.flac

07:23:34 : Test started.
07:23:57 : 01/01  50.0%
07:24:21 : 02/02  25.0%
07:24:48 : 02/03  50.0%
07:25:01 : 03/04  31.3%
07:25:17 : 04/05  18.8%
07:25:33 : 05/06  10.9%
07:25:57 : 06/07  6.3%
07:26:28 : 06/08  14.5%
07:27:10 : 07/09  9.0%
07:27:55 : 08/10  5.5%
07:28:47 : 08/11  11.3%
07:29:48 : 09/12  7.3%
07:30:06 : 10/13  4.6%
07:31:28 : 11/14  2.9%
07:32:22 : 11/15  5.9%
07:33:37 : 12/16  3.8%
07:33:47 : Test finished.

 ---------- 
Total: 12/16 (3.8%)

Code: [Select]

foo_abx 1.3.3 report
foobar2000 v0.9.6.4
2009/04/19 07:34:08

File A: C:\01- Abfahrt Hinwil (Artefact Only) Lossless.flac
File B: C:\01- Abfahrt Hinwil (Artefact Only) V1.1.3j -Q 2 --sortspread 3.lossy.flac

07:34:08 : Test started.
07:34:35 : 01/01  50.0%
07:35:09 : 02/02  25.0%
07:35:43 : 03/03  12.5%
07:36:11 : 03/04  31.3%
07:36:39 : 04/05  18.8%
07:37:03 : 05/06  10.9%
07:37:28 : 06/07  6.3%
07:37:46 : 07/08  3.5%
07:38:14 : 08/09  2.0%
07:38:50 : 08/10  5.5%
07:38:55 : Test finished.

 ---------- 
Total: 8/10 (5.5%)

Code: [Select]

foo_abx 1.3.3 report
foobar2000 v0.9.6.4
2009/04/19 07:42:02

File A: C:\00- Therion (Artefact+Context) Lossless.flac
File B: C:\00- Therion (Artefact+Context) V1.1.3j -Q 2.5.lossy.flac

07:42:02 : Test started.
07:42:42 : 00/01  100.0%
07:43:01 : 01/02  75.0%
07:43:31 : 01/03  87.5%
07:44:05 : 01/04  93.8%
07:44:24 : 02/05  81.3%
07:44:42 : 02/06  89.1%
07:45:12 : 03/07  77.3%
07:45:40 : 04/08  63.7%
07:45:51 : Test finished.

 ---------- 
Total: 4/8 (63.7%)

Code: [Select]

foo_abx 1.3.3 report
foobar2000 v0.9.6.4
2009/04/19 07:46:03

File A: C:\01- Abfahrt Hinwil (Artefact Only) Lossless.flac
File B: C:\01- Abfahrt Hinwil (Artefact Only) V1.1.3j -Q 2.5.lossy.flac

07:46:03 : Test started.
07:46:22 : 01/01  50.0%
07:46:36 : 01/02  75.0%
07:46:50 : 02/03  50.0%
07:47:12 : 03/04  31.3%
07:47:27 : 04/05  18.8%
07:47:56 : 04/06  34.4%
07:48:17 : 04/07  50.0%
07:48:36 : 04/08  63.7%
07:48:38 : Test finished.

 ---------- 
Total: 4/8 (63.7%)

lossyWAV 1.2.0 Development Thread

Reply #397 – 2009-04-19 08:19:48

This is actually very encouraging - although transparency is the goal, it is *not* the goal for --portable. lossyWAV *requires* to be transparent (as far as we know due to testing / samples / etc) at --standard. It's good to see how low down the quality scale the transparency point seems to be.

lossyWAV 1.2.0 Development Thread

Reply #398 – 2009-04-19 10:53:50

It's true that officially transparency was not the target for option '--portable'.
In practice however I see things have changed in users' minds. Despite the fact that in theory we would allow for small problems with --portable what most people really did is expect transparency for --portable, more or less. It took me a long time to do so (I sticked with standard) but facing the fact that --standard is overkill I jumped up the --portable expected transparency train as well.
And it's fine IMO. 2Bedecided's basic idea was great and worked well in the 500 kbps region from the very start. Your tuning details were great as well, Nick, and it is your merit that you brought transparency to lossyWAV in the 350...400 kbps region.
Maybe -q 2.5 is still overkill for 'practical transparency' (whatever this may mean exactly - something like allowing for a priori not exactly determined very small deviations from transparency), but the current proposals for additional switches on a smaller -q basis are only slight variations of the noise analysis as is. My gut feeling is that this won't really bring us forward, but it's also a bit dangerous in the face of the fact that what we've reached already is excellent. It's a bit dangerous as there is already a tendency that bitrate of our excellent quality settings have a strong tendency to go up, and it's also dangerous because changes in the machinery can also bring quality regression, be it simply because of implementation errors or by quality regressions of the new techniques which can remain unnoticed for a long time. IMO such a danger must be accepted when real new and promising ideas come up, but this is not the case IMO for the current variants of decision making based on the FFT analysis and also not for more elaborate variants of the FFT analyses itself. For these noise analysis variants my suggestion is as stated before: in order to be a promising variant bitrate for the --portable quality should go up more for a problem sample set than for a regular music sample set. If this is not the case I would not go into listening tests - all with respect to the fact that it's excellent already what we've got.

To back up what I mean in addition to what sauvage78 has found I just tested v1.1.3j on my typical sample set with bitrate in mind:

--portable      385 kbps
-q 2              371 kbps (not so much lower than --portable so not too attractive)
-q 2 -X 3       384 kbps (pretty useless compared to --portable especially as quality decreases)
-q 2 -s 0.3     376 kbps (as an alternative approach focusing on noise shaping instead of noise analysis variants)

In the end I think we can be very happy with plain --portable, and I stop using -a 5.
I think using a slightly stronger noise shaping like -s 0.3 or -s 0.35 for -q 2 and/or --portable can bring a slight advantage (in terms of a slight bitrate decrease and/or a slightly increased safety margin) against using plain --portable as it is now.

@sauvage78:
Thanks a lot for testing. Do you mind testing -q 2 -s 0.3 and/or -q 2 -s 0.35 ?

lossyWAV 1.2.0 Development Thread

Reply #399 – 2009-04-19 12:50:01

Because ABXing -q2 takes a time, I tried -s 0.35 at -q 0, for me -s 0.35 is a regression, it make sound slightly crackles.

Code: [Select]

foo_abx 1.3.3 report
foobar2000 v0.9.6.4
2009/04/19 13:38:33

File A: C:\00- Therion (Artefact+Context) V1.1.3j -Q 0 -s 0.35.lossy.flac
File B: C:\00- Therion (Artefact+Context) V1.1.3j -Q 0.lossy.flac

13:38:33 : Test started.
13:38:52 : 01/01  50.0%
13:39:01 : 02/02  25.0%
13:39:38 : 03/03  12.5%
13:40:18 : 04/04  6.3%
13:40:48 : 05/05  3.1%
13:41:08 : 06/06  1.6%
13:41:34 : 07/07  0.8%
13:41:51 : 08/08  0.4%
13:41:53 : Test finished.

 ---------- 
Total: 8/8 (0.4%)

Code: [Select]

foo_abx 1.3.3 report
foobar2000 v0.9.6.4
2009/04/19 13:43:06

File A: C:\01- Abfahrt Hinwil (Artefact Only) V1.1.3j -Q 0 -s 0.35.lossy.flac
File B: C:\01- Abfahrt Hinwil (Artefact Only) V1.1.3j -Q 0.lossy.flac

13:43:06 : Test started.
13:43:26 : 01/01  50.0%
13:43:38 : 02/02  25.0%
13:43:55 : 02/03  50.0%
13:44:08 : 02/04  68.8%
13:44:46 : 03/05  50.0%
13:45:04 : 04/06  34.4%
13:45:24 : 05/07  22.7%
13:45:38 : 06/08  14.5%
13:45:57 : 07/09  9.0%
13:46:20 : 07/10  17.2%
13:46:37 : 08/11  11.3%
13:47:04 : 09/12  7.3%
13:47:07 : Test finished.

 ---------- 
Total: 9/12 (7.3%)

IMHO the best thing to do is to release 1.2 as it is without all the additionnal parameters which have no "must have" gain. I switched back to the good'old -P which make me happier personnaly.

It's time to release 1.2 & start the Implementation of SG's new noise shaping method.

Notice