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 313397 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

lossyWAV 1.2.0 Development Thread

Reply #275 –
I noticed that http://lossywav.svn.sourceforge.net/viewvc/lossywav/ has not been updated since initial checkin, and the sourcecode link in the first post is also quite old.
Would be nice to see recent changes in svn, so that i could fix C# implementation accordingly, since there was at least one major change - a fix to the noise shaping algorithm.
CUETools 2.1.6

lossyWAV 1.2.0 Development Thread

Reply #276 –
I'll try to release beta 1.1.3 source this weekend.
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 #277 –
lossyWAV beta 1.1.3 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 #278 –
Following the reinstatement of the old spreading function in beta 1.1.3, I have been looking at a hybrid variant which adds the core of the new method with the process of the old. This slightly lowers bits-to-remove for some but not all of the files in my 55 problem sample set resulting in a fraction of 1kbps small increase in FLAC resultant bitrate. There is no real speed penalty associated with the variant spreading function when compared to either the new or old versions.

I will post beta 1.1.3c this evening which will incorporate -V or --varspread parmeter to allow the variant spreading function to be tested.

Following some discussion earlier in this thread, I will also take a stab at rewording the text describing the lossyWAV method itself.

[edit]
Code: [Select]
lossyWAV beta v1.1.3c indicative bitrates.
|-----|----------|----------|----------|----------|----------|----------|----------|
| SPR |--insane  |--extreme |--standard|--portable|  --zero  | --nasty  | --awful  |
|-----|----------|----------|----------|----------|----------|----------|----------|
| NEW | 651 kbps | 581 kbps | 505 kbps | 417 kbps | 313 kbps | 252 kbps | 205 kbps |
| OLD | 654 kbps | 584 kbps | 508 kbps | 425 kbps | 322 kbps | 257 kbps | 208 kbps |
| VAR | 659 kbps | 590 kbps | 514 kbps | 432 kbps | 327 kbps | 260 kbps | 210 kbps |
|-----|----------|----------|----------|----------|----------|----------|----------|
Table indicates resultant FLAC -b 512 -5 bitrates from processing of my 55 problem sample set.[/edit]
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 #279 –
Thanks for your work, Nick.
Can you describe a bit the new hybrid variant? I wasn't aware you introduced a new process with the new spreading function. I thought you just exchanged the arithmetic averaging for an average which gives a greater weight to the center bin (and use only an uneven number of bins so that there is a center bin).
I'll try your new variant within the next days. Increasing bitrate with problem samples is welcome especially if the bitrate increase is more with problems than with regular music.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.2.0 Development Thread

Reply #280 –
The variant is based on the old method in that it averages an integer number of bins. The new method takes a proportion of the two bins immediately adjacent to the centre bin and calculates the average [i.e. result = (fraction x (left_bin + right_bin) + centre_bin) / (1 + 2 x fraction)]. This takes a proportion between 0 and the maximum for that particular fft_length as the bin-frequency increases.

The variant takes the minimum of the old bin average and the new bin average as the bin-result. The lowest of there bin-results is used, as is the average of all of the bin-results calculated.

lossyWAV beta 1.1.3c 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 #281 –
Thanks, Nick, for the explanation. So the hybrid variant makes things more defensive. I like this in case bitrate of regular music doesn't increase a lot.
I couldn't resist and tried 1.1.3c on my regular tracks test set:

1.1.3c --portable: 376 kbps
1.1.3c --portable -O: 375 kbps
1.1.3c --portable -V: 383 kbps
1.1.3c --standard: 474 kbps
1.1.3c --standard -O: 466 kbps
1.1.3c --standard -V: 474 kbps

To me this is an insiginificant increase in bitrate.
I was astonished a bit that bitrate of -O is lower than that without this option.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.2.0 Development Thread

Reply #282 –
Thanks for the testing - I processed my 10 album test set and got 377kbps for -P and -P -O, but 385kbps for -P -V.

Now we need some critical ears to come forward and volunteer to ABX....
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 #283 –
It's been quite a while that I tested my problem sample set consisting of badvilbel, bibilolo, dither_noise_test, eig, furious, keys_1644ds, S37_OTHERS_MartenotWaves_A, under_the_boardwalk.

I started with the lowest setting -q 0.0 -V which yields an average bitrate of 280 kbps on average for my regular music test set (I still use FLAC -l 6 -e -m -r 2 which is a little bit slower than -5 but can save roughly 1 to 2 kbps when using --standard). Quality of the problem samples in general is astonishingly high. Pretty bad is only eig and furious. furious has a strange error in the 2.0...2.5 second range.

Using -q 0.5-V (301 kbps for my regular music test set) improves things a lot, but the issues with eig and furious are still easily abxable.

-q 1.0 -V (322 kbps on average for my regular test set) makes the problems acceptable to me though I can still abx them.

With -q 1.5 -V (344 kbps for my regular music) I could not abx the problems any more. I guess other testers will be able to abx them, may be I can do it when using a lot more effort (which however wouldn't have anything in common with my usual listening and so would be only of a theoretical value to me).

So from this (and listening to some regular music) I think -q 1.5 -V is a good setting for portable use. Or - in other words - --portable has already a certain safety margin for its intended use.

Guess I'll switch from --standard to --portable, with my new DAP I'm short on storage space anyway.

Thanks a lot, Nick, for your great work.
lame3995o -Q1.7 --lowpass 17
 

lossyWAV 1.2.0 Development Thread

Reply #284 –
Many thanks, as usual, for your listening time. I am pleased that --portable has proven in this instance to have an acceptable safety margin. The bitrates you are proposing using at -q 1.5 -V are also palatable at circa 350kbps for DAP use - less than 10% more than max.MP3. With the right player and FLAC's low processing load on decoding this may give a good battery life for your player.

As an aside, I recently purchased a Sansa Fuze which I am extremely impressed with. It plays FLAC (after a firmware update) and presents itself as two USB drives when plugged into my PC - 1 x 8GB (internal) and 1 x 16GB (microSDHC). The library function is seamless across the two storage areas so finding tracks (albums in my case) is simple.
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 #285 –
Quote from: Nick.C on
... I recently purchased a Sansa Fuze which I am extremely impressed with ... 1 x 8GB (internal) and 1 x 16GB (microSDHC). ...

With respect to storage space my Meizu M6 SL certainly wasn't a good choice. On the other hand sound quality is great - and probably it's not bad to get used to lossyWAV and mp3 settings a bit lower than what I was used to so far. Quality is excellent anyway.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.2.0 Development Thread

Reply #286 –
lossyWAV beta 1.1.3d 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 #287 –
Thanks, Nick, for your improvements.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.2.0 Development Thread

Reply #288 –
Quote from: Gregory S. Chudov on
I noticed that http://lossywav.svn.sourceforge.net/viewvc/lossywav/ has not been updated since initial checkin, and the sourcecode link in the first post is also quite old.
Would be nice to see recent changes in svn, so that i could fix C# implementation accordingly, since there was at least one major change - a fix to the noise shaping algorithm.


Hi there.

I'm back from some quite nasty personal problems (including very serious health problems). []

I noticed that since my first proposal to rewrite the code in C, some higher level implementations were made. This is good. I think, though, that it would be a good thing to have a C version of the code, since it would be good to profile the programs with both some already known code (especially for the FFT) and with libraries such as the liboil (oil = Optimized Inner Loops).

This would mean that we would have a moderately fast binary, portable to many operating systems and platforms of an entirely free tool that seems to be just what the doctor prescribed.

Well, Nick, where is the latest source code? Do you know how to use a version control system like SVN, where I put the source? It would be nice if we tagged the versions and created diffs so that we can see how the code progresses.


Regards, Rogério Brito.

P.S.: I see many threads here involving the lossyWAV development and I must confess that I'm slightly lost with all these releases.

lossyWAV 1.2.0 Development Thread

Reply #289 –
Hi Rogério,

I'm sorry to hear that you have had some problems - I hope that your health is improving and that life is getting better.

Gregory S. Chudov is leading the C conversion and [JAZ] has been working on a J version.

The latest source code is contained in the ZIP file "lossyWAV_Source_20090405_0732_beta_1.1.3d.zip" (obvious typo in the name ) which is attached to post #1 in this thread. I tend to attach revised source whenever I reach a stable beta.

I have no familiarity with diff files so have not been creating them. Equally, I have never used the SVN.

This thread is the only thread where any development is occurring - the other development and release threads are dormant as far as I'm concerned (unless someone revives them inadvertently).

On the development front I am awaiting feedback on the variant spreading function - I consider that it should be the only one remaining in the next version.
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 #290 –
I've been working on the code (as ever) and have made a few speed improvements in the Delphi code (of the order of a 25% reduction in processing time for --zero).

At the same time as this I have been working through the variant spreading function and am satisfied that it achieves its aim.

As an aside, I processed my 10 album test set at --portable --varspread --analyses 5 and the resultant FLAC -b 512 -5 bitrate was 397kbps (v1.1.0b --portable: 376kbps; v1.1.3d --portable --varspread: 385kbps). Although the processing time increased by about 60%, I feel that using three additional FFT lengths (128, 256 and 512 samples) catches more low dips in the noise floor.

So, in the imminent run-up to v1.2.0 I propose that the variant spreading function is adopted as the standard and that the existing "new" and "old" versions are removed. Also, SebastianG's proposed dynamic noise shaping method is to be deferred until v1.3.0.
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 #291 –
Quote from: Nick.C on
...So, in the imminent run-up to v1.2.0 I propose that the variant spreading function is adopted as the standard and that the existing "new" and "old" versions are removed. Also, SebastianG's proposed dynamic noise shaping method is to be deferred until v1.3.0.

I welcome this very much.

Quote from: Nick.C on
... I processed my 10 album test set at --portable --varspread --analyses 5 and the resultant FLAC -b 512 -5 bitrate was 397kbps (v1.1.0b --portable: 376kbps; v1.1.3d --portable --varspread: 385kbps).
...

What makes -V bitrate of your version under investigation increase compared to the v1.1.3d result?
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.2.0 Development Thread

Reply #292 –
The bitrate increase is due to the use of the additional analyses, the v1.1.3d -P -V result is for the standard two analyses.
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 #293 –
Quote from: Nick.C on
The bitrate increase is due to the use of the additional analyses, the v1.1.3d -P -V result is for the standard two analyses.

I welcome going more defensive especially as also to me -P now is the way to go.
However I feel that we should stop this some day cause otherwise we end up with a bitrate for -P which once was that of -S.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.2.0 Development Thread

Reply #294 –
I think it best that the user should select the number of analyses (between 2 (default) and 5 (maximum)) using the -a or --analyses parameter.
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 #295 –
Quote from: Nick.C on
I think it best that the user should select the number of analyses (between 2 (default) and 5 (maximum)) using the -a or --analyses parameter.

To me this is a good solution.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.2.0 Development Thread

Reply #296 –
I'll put out beta v1.1.3e tomorrow as a final beta before v1.2.0.
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 #297 –
lossyWAV beta v1.1.3e 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 #298 –
Quote from: halb27 on
I welcome going more defensive especially as also to me -P now is the way to go.
However I feel that we should stop this some day cause otherwise we end up with a bitrate for -P which once was that of -S.

What you say were also my thoughts when Nick introduced --varspread. Yes it is more defensive, but so is choosing a higher -q setting .
Everytime the bitrates changes, users should (in theory) find their sweetspot (size/quality) again.

Just a thought, but don't let it stop progress 
In theory, there is no difference between theory and practice. In practice there is.

lossyWAV 1.2.0 Development Thread

Reply #299 –
I *think* that the variant spreading function in conjunction with a slightly lower -q setting will give an overall better result in that the combination of spreading functions will spot dips in the noise floor better than either in isolation.

The resultant bitrate of the output from beta v1.1.3e at --quality 2.2 is the same as that for v1.1.0b --portable for my 55 problem sample set.
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)