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: lossyWAV 1.2.0 Development Thread (Read 311268 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

lossyWAV 1.2.0 Development Thread

Reply #325 –
lossyWAV beta v1.1.3f attached to post #1 in this thread.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.2.0 Development Thread

Reply #326 –
I tested --centre, I immediatly suspected a regression, but I couldn't ABX it & I quickly feel tired. I add a first row of seven success but then it became very random. I tried to re-focus in order to fall below 0.4%, so I went up to 10 then 12 then 16 trials but I always failed to recover.

Quote
foo_abx 1.3.3 report
foobar2000 v0.9.6.4 beta 2
2009/03/31 11:00:00

File A: D:\a00- Therion (Artefact+Context) -q 0 --centre.lossy.flac
File B: D:\a00- Therion (Artefact+Context) -q 0.lossy.flac

11:00:00 : Test started.
11:00:39 : 01/01  50.0%
11:01:10 : 02/02  25.0%
11:01:56 : 03/03  12.5%
11:02:34 : 04/04  6.3%
11:02:57 : 05/05  3.1%
11:03:52 : 06/06  1.6%
11:04:17 : 07/07  0.8%
11:05:17 : 07/08  3.5%
11:06:29 : 08/09  2.0%
11:07:49 : 08/10  5.5%
11:09:49 : 08/11  11.3%
11:10:29 : 09/12  7.3%
11:11:20 : 10/13  4.6%
11:12:28 : 11/14  2.9%
11:13:52 : 11/15  5.9%
11:16:27 : 12/16  3.8%
11:16:42 : Test finished.

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


I tried Abfahrt Hinwil to see if it weren't easier, same thing, I instantly suspected a regression & add a 7/8 success in the beginning then it became random, so I gave up.

Quote
foo_abx 1.3.3 report
foobar2000 v0.9.6.4 beta 2
2009/03/31 11:21:13

File A: D:\a01- Abfahrt Hinwil (Artefact+Context) -q 0.lossy.flac
File B: D:\a01- Abfahrt Hinwil (Artefact+Context) -q 0 --centre.lossy.flac

11:21:13 : Test started.
11:21:48 : 01/01  50.0%
11:22:14 : 02/02  25.0%
11:22:49 : 03/03  12.5%
11:23:34 : 04/04  6.3%
11:24:56 : 05/05  3.1%
11:25:39 : 05/06  10.9%
11:27:13 : 06/07  6.3%
11:28:10 : 07/08  3.5%
11:28:57 : 08/09  2.0%
11:31:31 : 08/10  5.5%
11:31:43 : Test finished.

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


I suspect that there is a slight regression that I could catch better after a night of sleep. The only thing I can tell for sure is that in no way there is a progression with --centre.
Personnaly, I am convinced there is a regression but I cannot seriously backup my claim. Even if my logs aren't really good, I am self confident because I know which artefact I was trying to catch: a very light crackling that was making the sound unstable on both samples (even on Abfahrt Hinwil which was more stable than Therion so far)
I will try the other setting later as I am not in the best mood for it actually. I'm asleep at the wheel.

lossyWAV 1.2.0 Development Thread

Reply #327 –
Sure I'm very conservative, but after having reached such a good quality with lossyWAV, Nick, I'm always afraid that with a changing machinery quality can get worse.
There's a golden way however by doing things the way you did them with -V or -a, that is going more defensive in a strict sense with a new machinery. This allows even for automatic testing, cause for every block of every sample thrown to a new machinery bits to remove should be equal or less than was the case with the current version.

In case of your central 1024 bin FFT it would mean doing it additionally to the end point centered FFTs and choose the lowest number of bits to remove.

All these things especially when done in the secure way described above makes the quality settings more defensive. This means we have to consider bitrate go up a bit (and encoding time increase). IMO this is welcome for the low quality settings in case we get a quality increase like the one reported by sauvage78. It's more questionable for --portable and above as quality is excellent already as known so far.

In order to give the user a choice maybe you can give him a switch (named --superanalysis or similar) which incorporates all this extra stuff which makes the machinery extra-defensive. May be it should be defaulted up to -q 1.5 or --portable.
Or the other way around: use --superanalysis as default (maybe up to a certain quality level like for instance --standard) and give the user the opportunity to use --standardanalysis.
When defaulting up to a specific quality level no matter which way --standardanalysis or --superanalysis would both be welcome for the user in order to use whatever he likes for every quality level.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.2.0 Development Thread

Reply #328 –
@sauvage78: Thanks for the testing - I expect --centre to change things slightly - how it changes them in terms of better or worse has yet to be determined.

@halb27: I think that removing --centre will be the outcome of this latest phase - unless someone finds a sample where it improves the output compared to the existing method. Adding extra FFT analyses at existing FFT lengths by reducing the FFT underlap between successive analyses should always be a conservative approach.

In the same way that adding additional FFT lengths to the analysis using the --analyses parameter examines different sample windows, the reduction in underlap length increases the number of FFT analyses for a current FFT length over the same data-range.

Quick check on resultant bitrates at --portable for my 55 problem sample set:

--underlap 1: 432.4kbps; (default)
--underlap 2: 443.0kbps;
--underlap 3: 453.9kbps;
--underlap 4: 465.3kbps;
--underlap 5: 477.0kbps;
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.2.0 Development Thread

Reply #329 –
I think all these things work together.

The point of the spreading functions is partly to match how the human ear works, but also partly to help iron out some of the inevitable, but insignificant (IMO) very low results in various random FFT bins. I know you tuned these spreading functions extensively previously.

If you add more analyses, you're increasing the chance of getting an insignificant very low FFT bin. You're also increasing the chance of spotting a real and significant dip in the spectrum.

It seems to me that if you get more of these pesky meaningless isolated very low FFT bins, then you might need more spreading to hide them; also, if you are going to spot more genuine dips (or spot them more reliably than before) then the ideal spreading might be more than you had before (because, presumably, if things worked OK before, the spreading must have been slightly conservative to account for the fact that you might half-miss some genuine spectral dips).

At the very least, it seems to me that having more FFT data available gives the chance (and it makes sense) to use some subtly different spreading.


So the "right" thing to do is figure out what magnitude of frequency dip you want to catch, and design the FFTs and spreading functions to ensure that you catch it.

Or, to put it another way, if it was working properly previously, then the "right" thing to do can't be to change one without the other. You need to experiment with both FFT properties and spreading functions.


Sounds like too much hard work to me...

Cheers,
David.

lossyWAV 1.2.0 Development Thread

Reply #330 –
I just tested --underlap 5, I first tried --underlap 8 as it is written up to 8 in the --longhelp but it crashed. I used -q 0 instead of -q 1 just to make the ABXing easier, the result is that --underlap 5 give result very similar to -a 5, there is a real gain. The result is almost the same as with -a 5, Therion became more stable (less random noise) & the volume of the artefact within Abfahrt Hinwil is reduced. It was much much easier to ABX than --centre. For testing purpose I begin to think that Abfahrt Hinwil is a better sample than Therion because it is less noisy & less tiring (Edit: not true for --centre). Is --underlap 5 supposed to be compatible with -a 5 ? Is it supposed to stack ?

Quote
foo_abx 1.3.3 report
foobar2000 v0.9.6.4 beta 2
2009/04/01 00:36:35

File A: D:\a00- Therion (Artefact+Context) -q 0 --underlap 5.lossy.flac
File B: D:\a00- Therion (Artefact+Context) -q 0.lossy.flac

00:36:35 : Test started.
00:37:00 : 01/01  50.0%
00:37:20 : 02/02  25.0%
00:37:41 : 03/03  12.5%
00:38:10 : 04/04  6.3%
00:38:31 : 05/05  3.1%
00:38:52 : 06/06  1.6%
00:39:10 : 07/07  0.8%
00:39:52 : 08/08  0.4%
00:39:54 : Test finished.

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


Quote
foo_abx 1.3.3 report
foobar2000 v0.9.6.4 beta 2
2009/04/01 00:43:44

File A: D:\01- Abfahrt Hinwil (Artefact Only) -q 0 --underlap 5.lossy.flac
File B: D:\01- Abfahrt Hinwil (Artefact Only) -q 0.lossy.flac

00:43:44 : Test started.
00:44:01 : 01/01  50.0%
00:44:12 : 02/02  25.0%
00:44:22 : 03/03  12.5%
00:44:29 : 04/04  6.3%
00:44:37 : 05/05  3.1%
00:44:49 : 06/06  1.6%
00:45:06 : 07/07  0.8%
00:45:20 : 08/08  0.4%
00:45:22 : Test finished.

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


Then I retried --centre as I was in better health than yesterday:

Quote
foo_abx 1.3.3 report
foobar2000 v0.9.6.4 beta 2
2009/04/01 01:03:05

File A: D:\00- Therion (Artefact+Context) -q 0.lossy.flac
File B: D:\00- Therion (Artefact+Context) -q 0 --centre.lossy.flac

01:03:05 : Test started.
01:03:38 : 01/01  50.0%
01:04:01 : 02/02  25.0%
01:04:24 : 03/03  12.5%
01:04:42 : 03/04  31.3%
01:05:03 : 04/05  18.8%
01:05:25 : 05/06  10.9%
01:05:57 : 06/07  6.3%
01:06:42 : 07/08  3.5%
01:07:24 : 08/09  2.0%
01:08:03 : 09/10  1.1%
01:08:15 : Test finished.

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


Quote
foo_abx 1.3.3 report
foobar2000 v0.9.6.4 beta 2
2009/04/01 01:09:06

File A: D:\01- Abfahrt Hinwil (Artefact Only) -q 0 --centre.lossy.flac
File B: D:\01- Abfahrt Hinwil (Artefact Only) -q 0.lossy.flac

01:09:06 : Test started.
01:09:28 : 01/01  50.0%
01:09:53 : 01/02  75.0%
01:10:57 : 02/03  50.0%
01:11:50 : 03/04  31.3%
01:12:06 : 03/05  50.0%
01:12:33 : 04/06  34.4%
01:13:15 : 04/07  50.0%
01:14:16 : 05/08  36.3%
01:15:12 : 06/09  25.4%
01:16:06 : 07/10  17.2%
01:16:14 : Test finished.

----------
Total: 7/10 (17.2%)


My personnal feeling is that there is a regression on the Therion sample, but that this regression affects Abfahrt Hinwil much less than the Therion sample. I tried twice & twice it happened that I highly suspected that Therion add some added cracklings. I add a raw of success yesterday on Abfahrt Hinwil but I couldn't reproduce this result today while my health was better. So personnaly I consider the first raw of success that I had yesterday on Abfahrt Hinwil as a possible raw of lucky guessing. It doesn't remove anything to the fact that there is no progression at all with --centre on any of the two killer samples & worst a possible regression (with high probability) on the Therion sample.

lossyWAV 1.2.0 Development Thread

Reply #331 –
@David: I think that I see what you mean with respect to significant vs insignificant dips. More FFT analyses of the same length within the same overall data range will presumably only spot more dips (if all of the previous analyses are still carried out). I also see what you mean about changes to the spreading function being "required" when more analyses are carried out.

As a clarification, more analyses in this sense is more overlapped FFT analyses within the same data range.

Adding extra FFT lengths to the overall analysis has a much more benign effect (see table below) so I think that the spreading function would require to be changed only if the underlap length is shortened.

For my 55 problem sample set (processed at --portable):
Code: [Select]
+--------------+--------------+--------------+--------------+--------------+--------------+
| beta v1.1.3f | --underlap 1 | --underlap 2 | --underlap 3 | --underlap 4 | --underlap 5 |
+--------------+--------------+--------------+--------------+--------------+--------------+
| --analyses 2 |   432.4kbps  |   443.0kbps  |   453.9kbps  |   465.3kbps  |   477.0kbps  |
| --analyses 3 |   438.2kbps  |   449.1kbps  |   460.7kbps  |   472.7kbps  |   485.0kbps  |
| --analyses 4 |   441.1kbps  |   452.2kbps  |   464.2kbps  |   476.5kbps  |   489.0kbps  |
| --analyses 5 |   443.6kbps  |   454.9kbps  |   467.1kbps  |   479.8kbps  |   492.6kbps  |
+--------------+--------------+--------------+--------------+--------------+--------------+


@sauvage78: Many thanks for the extensive testing. Taking into account David's suggestion regarding number of FFT analyses carried out on a data range requiring modifications to the spreading function, maybe the --centre parameter requires a change to be made to the spreading function for the 1024 sample FFT analysis.

The --underlap parameter description in the --longhelp is wrong, as you have already determined, the upper limit for --underlap is currently coded as 5.
I am still iterating with some ideas - will have another think and post revised code later (if I get anywhere).
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.2.0 Development Thread

Reply #332 –
Just a suggestion for quick checking whether new details in the machinery are worth testing:
Bitrate for a problem sample set should go up (in a significant way in an ideal world), while this shouldn't be the case for regular music.
In case bitrate increase is more or less the same for the two cases there is no reason to prefer a new mechanism over just increasing the quality setting.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.2.0 Development Thread

Reply #333 –
Absolutely.... .... but some "regular" music could suffer from the same artifact type as is being dealt with by the modified method.

I looked at reducing the underlap to 1 sample and all that really happened was that the resultant bitrate went to 399kbps for --zero --underlap 13 processing at  the standard two FFT lengths from 327kbps for the original method.

As an aside, and prompted by something David said, I am looking at (yet) another approach where the FFT results for the frequency bands of interest are sorted after taking their magnitude and multiplying by the skewing factor. After sorting (at the moment) the second lowest bin value is taken as the result and the minimum of that and the SNR adjusted average is taken as the overall result for that analysis. For my 10 Album Test Set, this results in:
Code: [Select]
+------------------------------------------------------------------------------------------------------+
¦   Version    ¦   FLAC   ¦ --insane ¦--extreme ¦--standard¦--portable¦  --zero  ¦ --nasty  | --awful  |
+--------------+----------+----------+----------+----------+----------+----------+----------+----------¦
¦Version 1.1.0b¦ 854kbit/s¦ 632kbit/s¦ 548kbit/s¦ 463kbit/s¦ 376kbit/s¦ 285kbit/s¦ -------- | -------- |
+--------------+----------+----------+----------+----------+----------+----------+----------+----------¦
¦ beta v1.1.3e ¦   "  "   ¦ 641kbit/s¦ 556kbit/s¦ 472kbit/s¦ 386kbit/s¦ 292kbit/s¦ 231kbit/s| 200kbit/s|
+--------------+----------+----------+----------+----------+----------+----------+----------+----------¦
| beta v1.1.3g |   "  "   ¦ 673kbit/s| 598kbit/s| 519kbit/s| 424kbit/s| 306kbit/s| 244kbit/s| 207kbit/s|
+------------------------------------------------------------------------------------------------------+
These results use the same corresponding noise-threshold-shift values used for the existing spreading function and do not necessarily reflect bitrates for a final version - I just thought that I would share these interim findings.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.2.0 Development Thread

Reply #334 –
Quote from: halb27 on
Just a suggestion for quick checking whether new details in the machinery are worth testing:
Bitrate for a problem sample set should go up (in a significant way in an ideal world), while this shouldn't be the case for regular music.
In case bitrate increase is more or less the same for the two cases there is no reason to prefer a new mechanism over just increasing the quality setting.
Exactly - there are a million different ways of pushing the bitrate up - but the ones that appear do this fairly uniformly across the board are just complicated ways of increasing the Q value.

However, I'm inclined to like mechanisms which make all moments sound equally bad, rather than those which leave audible differences in the "badness" experienced at different moments. So from this perspective, sauvage78's testing is encouraging.

Cheers,
David.

P.S. I'm still hoping that Nick will provide us with an explanation of the algorithm one day!

lossyWAV 1.2.0 Development Thread

Reply #335 –
Quote from: Nick.C on
... For my 10 Album Test Set, this results in: ...

IMO this way of going more defensive makes the low bitrate settings more useful in case a real quality improvement is experienced.
For --portable and above bitrate is too high for my taste especially as quality is excellent with what we have had so far.
Maybe it's a good thing to use these defensive variants up to -q 1.5 or similar in case of positive experience.

In any case I think it would be helpful to see bitrate increase percentage for a regular music and a problem sample set.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.2.0 Development Thread

Reply #336 –
halb27:
I don't understand your point in wishing to apply usefull parameters only to low/not transparent settings, -a 5 is usefull no matter the setting as it brings a quality improvement without a bitrate increase. As such, it should be used as default.

--underlap 5 is nice but it increases the bitrate, so the only thing that is needed to know is if --underlap 5 is better or not than just simply increasing the bitrate. Only a test with & without --underlap 5 at the same target bitrate can tell it. If --underlap 5 wins it should be defaulted, if it loses it should be improved or forgotten. This is not a question of good or bad setting, above or below --portable.

The only goals of lossywav should be to lower its transparency point in order to have even smaller files for DAP. It's a no-sense to artificially improve non-transparent setting by 0.25 by using special parameters on it ... it will not make them more tansparent, -q0 --underlap 5 is not better than -q0, both are rotten. If someone wants non-transparent lossy, he can use any other lossy codec at ~128Kbps, he will save much place. For me lossywav will swallow the niche that mpc had several years ago: audiophiles who don't care for bitrates, but only care for transparency on all kind of music (specially electronic music). The advantage of lossywav is not to be better or worse qualitywise than other lossy codecs, to me when transparency is reached they all sound the same. The advantage of lossywav is that it is affected by much less killer samples. Lossywav is a lossy codec with a bulletproof jacket on it.

-q 1.0 is usefull to find killer samples for lossywav, but I consider anything below -q 1.0 as not suited for any use I can think about.
Depending on your hearing skills -q 1.5, -q 2 & q 2.5 can be used for DAP,

-q 1.5 is non-transparent with light artefacts.
-q 2.0 is already really good but is likely to not be transparent on all future problem samples as the margin is low.
-q 2.5 is supposed transparent with a decent margin.

-q 5.0 is transparent with a huge margin for paranoid people. It remains to be proved that -q 5 is better for transcoding than -q 2.5.
Personnaly, I am convinced that nobody will ever be able to ABX this claim.

For me anything below -q 1.5 is non-sense as it is crap, anything above -q 2.5 is non-sense as it is huge.

I would rather use any pure lossy codec at ~128Kbps  than use lossywav at -q 0.
I would rather use any pure lossless codes at ~900Kbps than use lossywav at -q 5.

So lossywav should focus on what it does best, transparency for audiophile with DAP.
For me lossywav is not a flexible codec & it will never be.
There is no point in wishing that -q 0 would sound better if it is not transparent anyway: -q 0 is not like vorbis 64Kbps, nobody will ever stream it.

lossyWAV 1.2.0 Development Thread

Reply #337 –
I have a slightly different take on it.

The lowest setting needs to have audible problems (as I've said many times!). Those audible problems need to be related to the (hopefully inaudible) "problems" at higher settings. So you can't switch in a fundamentally different method for lower settings.

If you can change the algorithm and make a setting sound better at the same bitrate, then yes - change it - across the board though. Ditto if the change simply makes a given setting sound more consistent (at a similar bitrate to before) - because again that should be useful across the board.


I think lossyWAV with dynamic noise shaping (and maybe dynamic block size switching) could produce transparency at surprisingly low bitrates. Not mp3 bitrates, but not far off.

Cheers,
David.

lossyWAV 1.2.0 Development Thread

Reply #338 –
Quote from: sauvage78 on
halb27:
I don't understand your point in wishing to apply usefull parameters only to low/not transparent settings, -a 5 is usefull no matter the setting as it brings a quality improvement without a bitrate increase. ...
Actually I consider anything below -q1 as not suited for any use I can think about. Depending on your hearing skills -q 1.5, -q 2 & q 2.5 can be used for DAP,

-q 1.5 is non-transparent with light artefacts.
-q 2.0 is likely to not be transparent as the margin is low.
-q 2.5 is supposed transparent with a decent margin.

-q 5.0 is transparent with a huge margin for paranoid people....

I do use -a 5 with --portable thanks to your listening test.
Bitrate goes up with -a 5 (from 387 kbps to 400 kbps for my regular music test set).  I personally can live with this, but users should have some confidence that --portable bitrate remains roughly the same with new variants and there shouldn't be a steady upwards trend. Especially as -portable quality has been excellent.

My point is that I see it exactly like you: --portable so far can be expected to be transparent (without any further potential improverments of the machinery which always are also potentially risky when not done in a strictly defensive way), and the very edge of transparency is expected to be a little bit lower.
So any improvents in quality are most welcome for the lower quality settings, and it's matter of taste up to what quality level. If for instance -q 1.0 or -q 1.5 gets a more homogenous good quality (2Bdecided's idea) by a change in the machinery, and bitrate doesn't go up significantly to me this is the way to go. This is done by the -a 5 improvement you found.
But to me these things have their limit at least with a quality level of --portable. With the last thoughts about the machinery we get a bitrate of --portable which was that of --standard not a long time ago, and in this case I prefer the technical details of --standard, especially as this is the --standard machinery we do have quite a lot of experience meanwhile.
Different from you I see some usefulness also for the higher quality levels for which any bitrate increase is not so welcome because of great quality already achieved. The higher quality levels are useful for all those who don't need real lossless encodings but are content with lossy encodings of a quality that can be considered transparent with an extreme degree of confidence. Allows for a single collection.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.2.0 Development Thread

Reply #339 –
I know that --standard is interesting due to the history of lossywav & I think --standard is usefull as a high archor reference, but in all honesty --insane & --extreme are useless because the margin is much too wide. Using these two settings when -q 2.5 is already almost unABXable & -q 5 is unABXable at all, you will not increase the quality of your files, you will only waste space. I consider myself as a conservative user & even for me, this is obvious. The old 3 settings has always been the way to go for me. I still use lossywav this way -q 0/-q 2.5/-q 5. -q 0 is already bad enough to find killer samples, & -q5 is already good enough for paranoid audiophiles. I consider the other settings as missleading for new lossywav users, if you are an advanced user & want to test lossywav you can use the good'old quality scale. For serious testing purpose the actual presets are useless because you need much more accurate variation to tune lossywav. The -a 5 parameter is only a 0.25 gain on the quality scale. You cannot be so accurate with the presets, so telling the preset are made for tuning is a non-sense. --nasty & --awful are for deaf people. I agree that a very bad setting is needed, so I think -q -2.5 is more usefull than -q 7.5. Also having 4 setting is nice to create bitrates tables like Nick is doing regulary. 7 presets is too much IMHO. The good'old 3 presets + a very bad one are enough IMHO.

Because my test files are so short I didn't realize there could be a variation of ~15Kbps on real music that's why I didn't understood why you were so worried about non-transparent settings.

lossyWAV 1.2.0 Development Thread

Reply #340 –
All negative presets will be removed for v1.2.0.

Any bitrate less than the lossless FLAC is a saving - users should be permitted to select their own personal preference from FLAC - circa 20% to circa 300kbps.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.2.0 Development Thread

Reply #341 –
IMO too --portable and --standard are the most useful quality levels though I think --extreme is still useful for people using extreme quality lossyWAV as a substitute for lossless.
Anything else can go into the -q settings.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.2.0 Development Thread

Reply #342 –
IMO too --portable and --standard are the most useful quality levels though I think --extreme is still useful for people using extreme quality lossyWAV as a substitute for lossless.
Anything else can go into the -q settings.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.2.0 Development Thread

Reply #343 –
<feck> Mods, please delete this duplicate post.... Thankyou!
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.2.0 Development Thread

Reply #344 –
The extreme settings are (potentially) useful for transcoding and (almost certainly) useful for multi-generation use.

Cheers,
David.

lossyWAV 1.2.0 Development Thread

Reply #345 –
The results of a bit of comparative analysis:
Code: [Select]
10 Album Test Set
+------------------------------------------------------------------------------------------------------+
| beta v1.1.3g |   FLAC   | --insane |--extreme |--standard|--portable|  --zero  | --nasty  | --awful  |
|--------------+----------+----------+----------+----------+----------+----------+----------+----------|
|   default    | 854kbit/s| 641kbit/s| 558kbit/s| 472kbit/s| 386kbit/s| 292kbit/s| 231kbit/s| 200kbit/s|
|--------------+----------+----------+----------+----------+----------+----------+----------+----------|
| --sortspread |   "  "   | 646kbit/s| 569kbit/s| 488kbit/s| 399kbit/s| 294kbit/s| 236kbit/s| 204kbit/s|
+------------------------------------------------------------------------------------------------------+

55 Problem Sample Set
+------------------------------------------------------------------------------------------------------+
| beta v1.1.3g |   FLAC   | --insane |--extreme |--standard|--portable|  --zero  | --nasty  | --awful  |
|--------------+----------+----------+----------+----------+----------+----------+----------+----------|
|   default    | 782kbit/s| 660kbit/s| 591kbit/s| 515kbit/s| 432kbit/s| 327kbit/s| 260kbit/s| 218kbit/s|
|--------------+----------+----------+----------+----------+----------+----------+----------+----------|
| --sortspread |   "  "   | 655kbit/s| 590kbit/s| 518kbit/s| 437kbit/s| 326kbit/s| 262kbit/s| 220kbit/s|
+------------------------------------------------------------------------------------------------------+

55 Problem Sample Set (--analyses 5)
+------------------------------------------------------------------------------------------------------+
| beta v1.1.3g |   FLAC   | --insane |--extreme |--standard|--portable|  --zero  | --nasty  | --awful  |
|--------------+----------+----------+----------+----------+----------+----------+----------+----------|
|   default    | 782kbit/s| 667kbit/s| 601kbit/s| 527kbit/s| 444kbit/s| 334kbit/s| 265kbit/s| 221kbit/s|
|--------------+----------+----------+----------+----------+----------+----------+----------+----------|
| --sortspread |   "  "   | 663kbit/s| 599kbit/s| 529kbit/s| 447kbit/s| 332kbit/s| 266kbit/s| 222kbit/s|
+------------------------------------------------------------------------------------------------------+


I'll try to post beta v1.1.3g this evening.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)
 

lossyWAV 1.2.0 Development Thread

Reply #346 –
Looking at this --sortspread is not very promising. Bitrate increase is higher for regular music than for problem samples.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.2.0 Development Thread

Reply #347 –
I'm still tuning the changes to the noise-threshold-shift values. As there is *no* averaging involved, I feel that --sortspread will find true holes more effectively (and ignore the first one).

I think that what it is finding in the 10 Album Test Set are potential problems which have not been recognised. The increase in 10 set bitrate when compared to the increase in 55 set bitrate is counterintuitive - so maybe it is finding something - or maybe it is padding the sausage.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.2.0 Development Thread

Reply #348 –
lossyWAV beta v1.1.3g attached to post #1 in this thread.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.2.0 Development Thread

Reply #349 –
For me, settings > --standard are useful, and one cannot look at lossywav in isolation in regards to --extreme etc .. Until there's a transcoding test from the various transparent lossywav settings to LAME at -v 5 and above, I'll remain a crazy in Sauvage's eyes. I've noticed for some samples there's a difference in bitrate from transcoding from TAK > MP3 as against Lossy.TAK > MP3. I'm guessing LAME is encoding some of that added noise.

And as Nick, 2Bdecided and Halb27 have pointed out, some people (me included) use LossyWAV as a substitute for lossless, so LossyWAV files become the source files for any transcodes.

C.

p.s. I liked this from Sauvage:

Quote
Lossywav is a lossy codec with a bulletproof jacket on it.
PC = TAK + LossyWAV  ::  Portable = Opus (130)