HydrogenAudio

Lossy Audio Compression => Other Lossy Codecs => Topic started by: Nick.C on 2015-05-19 09:40:20

Title: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Nick.C on 2015-05-19 09:40:20
Following the completion of the transcode from Delphi/ASM to C++ (thanks again to Tycho for initiating that process!!), a couple of bugs have required a small patch, so I'm using that as an excuse to start a new development thread....



Changelog:

lossyWAV v1.4.2 15/09/2016
Spoiler (click to show/hide)
Title: lossyWAV 1.5.0 Development
Post by: Fairy on 2015-05-19 12:40:13
Following the completion of the transcode from Delphi/ASM to C++ (thanks again to Tycho for initiating that process!!), a couple of bugs have required a small patch, so I'm using that as an excuse to start a new development thread....

Changelog:

lossyWAV v1.4.1a 19/05/2015
  • Cosmetic issue regarding display of time corrected (thanks Atak_Snajpera for bringing this to my attention);
  • Bug in input scaling corrected (not an issue if scaling was not used previously while processing).


"Added noise linear PCM bitdepth reduction method"

The changlog doesn't mention this...

Could you explain what has changes since 1.4.0 ? How exactly does 'noise linear PCM bitdepth reduction' work?

When I have some time left I will test and see the differences.

Happy to see there is still development going on.
Title: lossyWAV 1.5.0 Development
Post by: Nick.C on 2015-05-19 12:52:55
"Added noise linear PCM bitdepth reduction method"

The changlog doesn't mention this...


A sub-title has been in place for every version of lossyWAV development - previously it has been "Added noise WAV bitdepth reduction method" in 1.3.0, 1.2.0 and 1.1.0.

Basically, rounding off LSBs introduces noise (shaped or otherwise) and lossyWAV only processes linear PCM audio in WAV / WAV64 or RF64 files - nothing has changed, except the description, slightly.
Title: lossyWAV 1.5.0 Development
Post by: Fairy on 2015-05-19 13:07:49
Oops, indeed...

PS. now I'm still interested in the extreme modes I mentioned earlier. Is there a way you could add an "over the top" mode so the artifacts become very clear?
I would like to see where the artifacts become clear and tune it unit I cannot hear any diffirence and then compare the size of that file to the xtraportable mode.

I hope something like that is easy to implement and you are willing to do that some time

I will use it in my car again. Had some issues (flac in general) but I have flashed a new version to it so maybe I can enjoy lossyflac there (in xxxxxtra portable mode  )
Title: lossyWAV 1.5.0 Development
Post by: Nick.C on 2015-05-19 13:11:18
PS. now I'm still interested in the extreme modes I mentioned earlier. Is there a way you could add an "over the top" mode so the artifacts become very clear?
I would like to see where the artifacts become clear and tune it unit I cannot hear any diffirence and then compare the size of that file to the xtraportable mode.

I hope something like that is easy to implement and you are willing to do that some time


Anything is possible - if I do create such a beta version with more aggressive preset(s) then it will be time limited (as previous development versions have been).

It should be noted that Beta 1.4.1a is not time limited as the patches are considered to be final in and of themselves.
Title: lossyWAV 1.5.0 Development
Post by: Fairy on 2015-05-19 14:47:12
PS. now I'm still interested in the extreme modes I mentioned earlier. Is there a way you could add an "over the top" mode so the artifacts become very clear?
I would like to see where the artifacts become clear and tune it unit I cannot hear any difference and then compare the size of that file to the xtraportable mode.

I hope something like that is easy to implement and you are willing to do that some time


Anything is possible - if I do create such a beta version with more aggressive preset(s) then it will be time limited (as previous development versions have been).

It should be noted that Beta 1.4.1a is not time limited as the patches are considered to be final in and of themselves.


Is such a version will be made available, please let me know
I'd love to play with these settings/options !

PS. Maybe an extra setting for noisy environments like a car. Extra small files... I wonder how 192kbit/s lossyflac files sound like.
Title: lossyWAV 1.5.0 Development
Post by: Nick.C on 2015-05-19 15:09:32
Is such a version will be made available, please let me know
I'd love to play with these settings/options !

PS. Maybe an extra setting for noisy environments like a car. Extra small files... I wonder how 192kbit/s lossyflac files sound like.


The "problem" with assuming that cars are noisy is that they are not permanently so - stop by the roadside and, even with the engine running, the noise is significantly reduced when compared to motorway speeds. Shut the engine off and there's even less noise. That said, even eXtraportable is probably a bit on the cautious side with respect to internal settings (at least it was meant to be).

I'll give it a go and revert, as and when I have something to offer in that regard.
Title: lossyWAV 1.5.0 Development
Post by: Fairy on 2015-05-19 15:20:17
Is such a version will be made available, please let me know
I'd love to play with these settings/options !

PS. Maybe an extra setting for noisy environments like a car. Extra small files... I wonder how 192kbit/s lossyflac files sound like.


The "problem" with assuming that cars are noisy is that they are not permanently so - stop by the roadside and, even with the engine running, the noise is significantly reduced when compared to motorway speeds. Shut the engine off and there's even less noise. That said, even eXtraportable is probably a bit on the cautious side with respect to internal settings (at least it was meant to be).

I'll give it a go and revert, as and when I have something to offer in that regard.


I'll keep an eye on this topic

Of course, in the car there can be quiet moments, but using an ultraportable flac conversion is choice, and when doing that you're aware of certain artifacts. Lots of people drive around with 64kbit/s music in their cars and enjoying them. These people rather have a thousand 64kbit songs on a stick than a hundred flac's. This could be something in between.

Overall, I cannot image it sounds thát bad
Title: lossyWAV 1.5.0 Development
Post by: 2Bdecided on 2015-05-19 15:37:40
You can try the following with any lossyWAV quality setting you wish.

1. Run lossyWAV with the -C switch to generate a "correction" file (as well as a lossy processed file).
2. Load the original file and the correction file into a multitrack audio editor like Audacity so they play back at the same time.
3. Invert the correction file (optional, but best practice).
4. Increase the volume of the correction file until you can hear it above the original audio file.

There you have it: audible lossyWAV artefacts. Enjoy!

5. Decrease the volume of the correction file until you can no longer hear the artefacts.
If the gain is less than 0dB (i.e. negative; the correction file is now quieter than it was to start with) then the lossy encoding was probably not transparent to you.
If the gain is more than 0dB, then the lossy encoding was probably transparent to you, or you need to concentrate more carefully to hear and/or learn the artefacts.


It's not exactly what lossyWAV will do if you force the quality down, but it's close enough in terms of what it sounds like, and this is an easy way of learning the sound of lossyWAV artefacts.

This way you can also discover the sound and level of the artefacts at the various quality settings, by making them far louder (and hence audible). Unless you listen to the correction file on its own, or increase its level significantly in the above method, you aren't likely to hear what's done in standard or insane quality.

Cheers,
David.
Title: lossyWAV 1.5.0 Development
Post by: Fairy on 2015-05-20 07:57:08
You can try the following with any lossyWAV quality setting you wish.

1. Run lossyWAV with the -C switch to generate a "correction" file (as well as a lossy processed file).
2. Load the original file and the correction file into a multitrack audio editor like Audacity so they play back at the same time.
3. Invert the correction file (optional, but best practice).
4. Increase the volume of the correction file until you can hear it above the original audio file.

There you have it: audible lossyWAV artefacts. Enjoy!

5. Decrease the volume of the correction file until you can no longer hear the artefacts.
If the gain is less than 0dB (i.e. negative; the correction file is now quieter than it was to start with) then the lossy encoding was probably not transparent to you.
If the gain is more than 0dB, then the lossy encoding was probably transparent to you, or you need to concentrate more carefully to hear and/or learn the artefacts.


It's not exactly what lossyWAV will do if you force the quality down, but it's close enough in terms of what it sounds like, and this is an easy way of learning the sound of lossyWAV artefacts.

This way you can also discover the sound and level of the artefacts at the various quality settings, by making them far louder (and hence audible). Unless you listen to the correction file on its own, or increase its level significantly in the above method, you aren't likely to hear what's done in standard or insane quality.

Cheers,
David.


Thanks, but partially been there and have done that already. Not the amplification, but extracting the difference between the files. I used another way in audiacity bij subtracting the original vs the lossywav version. I only doubt the artifacts will be the same. I have done the same for ogg and mp3 compression. With ogg you can easily prove the difference files tells nothing about the sound quality. Even at very low bitrates the difference file sounds very quiet, but the compressed file sound awful. That means that listening to a separate difference file tells nothing about sound quality of the other file.

I hope Nick.C will come with a version that has some more options te play with. Would be really cool 
Title: lossyWAV 1.5.0 Development
Post by: 2Bdecided on 2015-05-20 09:07:46
I didn't suggest listening to the difference/correction file on its own. I suggested adding it back to the original file, but louder. It doesn't accurately simulate what a lower quality mode would do, but it usually makes the artefacts from the actual quality setting you chose easier to hear, which seems to be what you need.

Cheers,
David.
Title: lossyWAV 1.5.0 Development
Post by: Fairy on 2015-05-20 12:50:54
I didn't suggest listening to the difference/correction file on its own. I suggested adding it back to the original file, but louder. It doesn't accurately simulate what a lower quality mode would do, but it usually makes the artefacts from the actual quality setting you chose easier to hear, which seems to be what you need.

Cheers,
David.


I understand what you meant adding it back to the file. I just wanted to mention that a difference file (on it's own) doesn't tell anything about the sound quality. Even af very low bitrates the differences are quite minimal.

It's just funny that adding the difference file to a 64kbit low quality recording makes it sound like CD quality again while the difference file on it's own just sound like a bit of noise.

I'm going to try the suggested method asap.
Title: lossyWAV 1.5.0 Development
Post by: tycho on 2015-05-20 15:54:03
Hi Nick, David,

Just stopping by to say that it's great to see you still work on this project. I love the concept of lossyWAV, which is obviously why I initiated the translation into a more accessible language (but it was fun too).

Cheers,
Tycho.
Title: lossyWAV 1.5.0 Development
Post by: Nick.C on 2015-05-20 18:14:23
Just stopping by to say that it's great to see you still work on this project. I love the concept of lossyWAV, which is obviously why I initiated the translation into a more accessible language (but it was fun too).


Good to hear from you! Still enjoying working with the codebase - trying to identify new tweaks to make that may allow more bits to be removed (while not too adversely affecting output quality....). The best bit is that C++ seems to be faster than the Delphi / ASM version!
Title: lossyWAV 1.5.0 Development
Post by: Nick.C on 2015-05-21 09:47:31
lossyWAV beta 1.4.1b attached to post #1 in this thread.

Processing my 10 album test set using "-q M" results in a bitrate (FLAC -8, -b 512) of 241 kbit/s.
Title: lossyWAV 1.5.0 Development
Post by: Fairy on 2015-05-21 11:35:45
lossyWAV beta 1.4.1b attached to post #1 in this thread.

Processing my 10 album test set using "-q M" results in a bitrate (FLAC -8, -b 512) of 241 kbit/s.


Thanks a lot!

I'm at work now so cannot yet test, but can't wait to do that

Just spotted the 'agressive' and 'maniacal' options. Will test asap in my car system to see if I can spot differences in a noisy environment.






Title: lossyWAV 1.5.0 Development
Post by: Fairy on 2015-05-21 20:21:31
Just tried the new version

The aggressive mode is quite usable, but off course with audible noise, so not for hifi enviroments. For testing it is perfect, to check for weak points in a recording so you can set the appropriate quality mode.

I found that the maniacal comes close to 8 bit sound, but also a very good option to teach yourself to recognise the artifacts that LossyWav introduces.
The difference in bitrate between maniacal and aggressive if very small, but the difference in soundquality is quite huge. The same goes for aggressive vs extraportable, the difference in bitrate between those two is also quite small, but extraportable is close to transparent to me.

With the help of the extra 2 modes I finally found a way to hear differences between extraportable and the original, now that i know the details I have to listen to.

Thanks again
Title: lossyWAV 1.5.0 Development
Post by: GeSomeone on 2015-05-22 13:40:10
The aggressive mode is quite usable, but off course with audible noise,

Next you should try if your chosen lossyWav(+Flac) quality does sound actually better, in your car, than a lossy codec with a perceptible model (like LAME or (ogg)Vorbis). The latter will save considerably more space.

BTW. It's a pity that this thread about lossyWAV 1.5.0. isn't about 1.5.0 at all. Could we start again please? 
Title: lossyWAV 1.5.0 Development
Post by: Fairy on 2015-05-23 11:37:14
The aggressive mode is quite usable, but off course with audible noise,

Next you should try if your chosen lossyWav(+Flac) quality does sound actually better, in your car, than a lossy codec with a perceptible model (like LAME or (ogg)Vorbis). The latter will save considerably more space.

BTW. It's a pity that this thread about lossyWAV 1.5.0. isn't about 1.5.0 at all. Could we start again please? 


I am aware that overall quality of MP3 and Vorbis at these bitrates is a better choice, but to understand the technology of LossyWav and the audibility of the artifacts there has to be some extreme settings. From that there are possibilities to further optimize by people who know how to do that.

I do not see why this has nothing to do with the development. Your comment doesn't either, so please start.... You first?
Title: lossyWAV 1.5.0 Development
Post by: Bullit on 2015-06-19 03:36:37
What's the difference between LossyWAV and WAVPack lossy? Besides the portability, is there any difference in quality?

WAVPack claims to not use any psychoacoustic modelling.

Also great work on lossyWAV, saved me lots of space. Huge pain to use, shame there's no way to use in dBPoweramp.
Title: lossyWAV 1.5.0 Development
Post by: bryant on 2015-06-19 04:36:09
What's the difference between LossyWAV and WAVPack lossy? Besides the portability, is there any difference in quality?

WavPack lossy and lossyWAV are similar in that they both save space by changing the quantization resolution. LossyWAV can only do this in increments of 1 bit (6 dB), but uses some sort of psychoacoustic analysis to determine the optimum number of integer bits to remove at each instant. WavPack lossy can vary the quantization in essentially infinite steps, but does not have psychoacoustic analysis to drive the reduction and instead just has a user-specified target bitrate that it holds (technically, this is only a limitation of the implementation; the format supports more complex scenarios).

Both WavPack lossy and lossyWAV have noise shaping to make the quantization noise less audible, but lossyWAV's is much more sophisticated. On the other hand, WavPack lossy can use joint stereo which helps mask the quantization noise by moving it spatially instead of spectrally.

Given all this, my understanding is that WavPack lossy achieves similar quality to lossyWAV at a somewhat lower bitrate. Of course, the genius of lossyWAV is that the resulting FLAC files are completely compatible with all existing FLAC players (I'm not sure I understand the point of using lossyWAV with anything besides FLAC). Unfortunately, this compatibility puts some hard restraints on some of the techniques that could be used to improve the quality.
Title: lossyWAV 1.5.0 Development
Post by: halb27 on 2015-06-19 06:43:41
I also see the usefulness only with FLAC. FLAC usage is the big plus.
But what quality restraint should come from FLAC usage? We have a blocksize restraint, but this is not about quality. It's also not about FLAC but about the fact that blocksize has to be small in order to have a significant bitdepth reduction for many blocks.
The intrinsic idea of bit depth reduction has this as a consequence, at least for any following procedure which makes use of a fixed blocksize.
Title: lossyWAV 1.5.0 Development
Post by: bryant on 2015-06-19 07:06:25
But what quality restraint should come from FLAC usage? We have a blocksize restraint, but this is not about quality. It's also not about FLAC but about the fact that blocksize has to be small in order to have a significant bitdepth reduction for many blocks.

I didn't mean to imply that the restraints had anything to do with FLAC. The restraints (like no joint stereo) come from the fact that the lossyWAV PCM output must be playable as-is. But as you mention it, yeah, the fixed block size doesn't help either.

Title: lossyWAV 1.5.0 Development
Post by: Skymmer on 2015-06-22 20:05:20
I'm not sure I understand the point of using lossyWAV with anything besides FLAC

I also see the usefulness only with FLAC. FLAC usage is the big plus.

The fact that FLAC is the most popular lossless project doesn't mean that there are no other lossless codecs to choose from.
Let me remind you gentlemans that at some point of TAK development there were two codecs inside the TAK - default and another one specially tuned for LossyWav processed files.
Here is the little test.

Code: [Select]
Coldcut - Let Us Play (1997)
Used as image, 786 235 874 bytes, LossyWav 1.4.0 -q S

                                              enc.size      enc.time     enc.mem
                                            -----------     ---------    --------
flac 1.3.1           -8 --blocksize=512     241 393 727     38.093s      13MB
takc 2.1.0 Beta3b    -e -p4m -tn4 -cLW      215 280 441     29.765s       5MB

So TAK gives 10.8% better compression, takes less memory and runs 21.9% faster. So I can't even imagine a hypothetical situation where I should stick with FLAC for LossyWav files.
Title: lossyWAV 1.5.0 Development
Post by: halb27 on 2015-06-22 22:02:26
TAK is an alternative,  yes.
But a lossy codec is used for portable devices usually, and for this FLAC is supposed to be the codec of choice for most users.
BTW,  is 10% better compression typical for compressing lossyWAV files? This would be a remarkable improvement over FLAC IMO.
Title: lossyWAV 1.5.0 Development
Post by: SokilOff on 2015-06-23 01:40:15
TAK is an alternative,  yes.
But a lossy codec is used for portable devices usually, and for this FLAC is supposed to be the codec of choice for most users.

Well... correct me if I'm wrong, but FLAC is supposed to be the lossless codec of choice for many users. If user needs lossy codec it's much easier (and, probably, more efficient) to use "traditional" MP3, OGG or AAC.
Title: lossyWAV 1.5.0 Development
Post by: nu774 on 2015-06-23 07:47:00
TAK is an alternative,  yes.
But a lossy codec is used for portable devices usually, and for this FLAC is supposed to be the codec of choice for most users.

Well... correct me if I'm wrong, but FLAC is supposed to be the lossless codec of choice for many users. If user needs lossy codec it's much easier (and, probably, more efficient) to use "traditional" MP3, OGG or AAC.

Well, he is just comparing lossyFLAC and lossyTAK, and saying that lossyTAK might not be chosen because it's basically available only on PC, and on PC lossless is preferable.

That being said, indeed MP3 (or AAC/Vorbis) is far more popular, widely supported, efficient on lower bitrate than lossyFLAC.
However, lossyFLAC also has it's own good points, reasons to choose it.
- FLAC decoder consumes a lot less CPU power than MP3 (good for battery life).
- FLAC is always gapless. No delays, no extra padding. Even by players that doesn't support gapless playback of MP3 or AAC through LAME/iTunes specific tag hacks. Even when remuxed into another container such as Matroska.
Title: lossyWAV 1.5.0 Development
Post by: Fairy on 2015-06-23 12:34:14
TAK is an alternative,  yes.
But a lossy codec is used for portable devices usually, and for this FLAC is supposed to be the codec of choice for most users.

Well... correct me if I'm wrong, but FLAC is supposed to be the lossless codec of choice for many users. If user needs lossy codec it's much easier (and, probably, more efficient) to use "traditional" MP3, OGG or AAC.

Well, he is just comparing lossyFLAC and lossyTAK, and saying that lossyTAK might not be chosen because it's basically available only on PC, and on PC lossless is preferable.

That being said, indeed MP3 (or AAC/Vorbis) is far more popular, widely supported, efficient on lower bitrate than lossyFLAC.
However, lossyFLAC also has it's own good points, reasons to choose it.
- FLAC decoder consumes a lot less CPU power than MP3 (good for battery life).
- FLAC is always gapless. No delays, no extra padding. Even by players that doesn't support gapless playback of MP3 or AAC through LAME/iTunes specific tag hacks. Even when remuxed into another container such as Matroska.


And also LossyFLAC is (to my ears) absolutely 100% transparent at standard settings and the bitrate is half the bitrate of the original. MP3 and AAC are never transparent. Off course this leaves room for discussion, but I prefer LossyFLAC above any lossy codec. Still I have my entire collection on lossless flac, because 1: Space is not an issue on my NAS servers.
2: LossyFLAC development is still going on so I don't want to turn the switch yet.

For portable use I do use LossyFLAC.
Title: lossyWAV 1.5.0 Development
Post by: lvqcl on 2015-06-23 14:48:21
Current LossyWAV algorithm (with noise shaping etc) is quite slow, so the encoding time doesn't matter much. Besides, LossyWAV-specific codec was removed from the release version of TAK.
Title: lossyWAV 1.5.0 Development
Post by: punkrockdude on 2015-07-13 15:22:00
Not thread specific but, once again, thank you for creating this codec. I now it for archival because I have limited disk space and I haven't heard a difference.
Title: lossyWAV 1.5.0 Development
Post by: Musique-Rabbit on 2015-07-13 15:47:34
My collection is entirely LossyFLAC, except some hard-to-compress tracks such as piano solo.
Title: lossyWAV 1.5.0 Development
Post by: Fairy on 2015-10-21 14:49:35
Any updates in development? Maybe plans?

Thanks
Title: lossyWAV 1.5.0 Development
Post by: Nick.C on 2015-11-02 09:18:32
Any updates in development? Maybe plans?

Thanks


There's nothing in particular being worked on at the moment - so unless I have a "great idea" that turns into a development theme shortly then I'll be releasing the amended version as 1.4.1 next month.
Title: lossyWAV 1.5.0 Development
Post by: Nick.C on 2015-12-09 16:06:34
lossyWAV beta 1.4.1g attached to post #1 in this thread.

I've compiled the 32-bit and 64-bit versions with MinGW 5.2.0 (and added a few more compiler directives) - the 64-bit version in particular sees a fairly large speed boost on my development machine - the internal FFT routines seem to be about as fast as when FFTW is used.
Title: lossyWAV 1.5.0 Development
Post by: bubblebobble on 2015-12-09 23:44:48
I'm very newbie sorry, I tried to convert the same song from FLAC to lossyFlac with lossyWAV v1.4.0 and then with lossyWAV v1.4.1g and the result is the same file. I mean exactly the same, tested with MD5 check.

Using Foobar "std": lossywav - --quality standard --silent --stdout|flac - -b 512 -5 -f -o%d --ignore-chunk-sizes

Is this normal? thanks
Title: lossyWAV 1.5.0 Development
Post by: Nick.C on 2015-12-10 08:27:03
I'm very newbie sorry, I tried to convert the same song from FLAC to lossyFlac with lossyWAV v1.4.0 and then with lossyWAV v1.4.1g and the result is the same file. I mean exactly the same, tested with MD5 check.

Using Foobar "std": lossywav - --quality standard --silent --stdout|flac - -b 512 -5 -f -o%d --ignore-chunk-sizes

Is this normal? thanks


Entirely normal (good to hear, in fact) - there has been no change to the algorithm used in the DSP.
Title: lossyWAV 1.5.0 Development
Post by: Musique-Rabbit on 2015-12-10 09:53:54
Ha, just about to knock your door hard for the old drop dead date and here is a new one.

Thanks, Nick.
Title: lossyWAV 1.5.0 Development
Post by: bubblebobble on 2015-12-11 20:59:44
I can report an extremely good time gain, in my test I've converted in lossyFlac std the same 9 files, original Flac 950+ kbps total size 273mb:
lossyWAV v1.4.0 time = 3:15
lossyWAV v1.4.1g time = 2:05

total size came down to 122mb, same md5 for both lossyWav (as usual now I can say!)

Thank you very much for this update, Nick!
@Musique-Rabbit thank you also for answering to my pm time ago
Title: lossyWAV 1.5.0 Development
Post by: Nick.C on 2015-12-12 11:25:39
Glad to hear that the performance improvement exists on more than one machine....

To reduce file-size further, I use "-P=4096" to reduce the FLAC file padding from a default 65536 bytes and use "-8" as the FLAC compression preset. This reduces filesize with a small increase in compression time.
Title: lossyWAV 1.5.0 Development
Post by: Fairy on 2016-01-05 14:48:16
Glad to hear that the performance improvement exists on more than one machine....

To reduce file-size further, I use "-P=4096" to reduce the FLAC file padding from a default 65536 bytes and use "-8" as the FLAC compression preset. This reduces filesize with a small increase in compression time.


Hi Nick,

Do you know what happens when you exceed the padding size after editing? Normally the padding range is overwritten when adding metadata, but when there is more than 4096 bytes to be written, will the file be written over with a larger padding block of will changes fail from that moment on...

Thanks
Title: lossyWAV 1.5.0 Development
Post by: Nick.C on 2016-01-05 19:57:28
I tend to do my conversion / tagging in foobar2000 - it seems to checks for padding overflows in some way and rewrites the file with more padding if required.
Title: lossyWAV 1.5.0 Development
Post by: Nick.C on 2016-01-06 13:01:08
lossyWAV beta 1.4.1h attached to post #1 in this thread.
Title: lossyWAV 1.5.0 Development
Post by: alter4 on 2016-01-06 14:22:05
There's nothing in particular being worked on at the moment - so unless I have a "great idea" that turns into a development theme shortly then I'll be releasing the amended version as 1.4.1 next month.

That is good because I'd like the fix of checking function to be available in stable branch. Also I did some ABX tests on extraportable setting. From 7 sample only one fails, other are transparent. I can't say something wrong with my equipment or ears because I am able to ABX Lame or Vorbis 128 bitrate on many my samples.

Awesome tool I found. Thank you Nick.C and guys for your work!
Title: Re: lossyWAV 1.5.0 Development
Post by: Nick.C on 2016-02-05 14:12:10
lossyWAV beta 1.4.1i attached to post #1 in this thread.
Title: Re: lossyWAV 1.5.0 Development
Post by: Nick.C on 2016-02-26 14:34:47
lossyWAV beta 1.4.1j attached to post #1 in this thread.
Title: Re: lossyWAV 1.5.0 Development
Post by: Nick.C on 2016-02-26 20:27:45
Any comments regarding the new hybrid shaping would be very much appreciated.
Title: Re: lossyWAV 1.5.0 Development
Post by: duelle on 2016-03-03 00:49:20
Trying to get lossyWAV working in foobar2000. I based my settings on the one's in Nick's signature. I keep getting an error when converting.

Code: [Select]
An error occurred while writing to file (The encoder has terminated prematurely with code 0 (0x00000000); please re-check parameters) 

Additional information:
  Encoder stream format: 96000Hz / 2ch / 24bps
  Command line: "C:\Windows\SysWOW64\cmd.exe" /d /c C:\"Program Files"\lossyWAV.exe -q C -a 4 -s h -A --feedback 1 --stdout|C:\"Program Files"\flac.exe -8 -e -p -b 512 -P=4096 -S -o%d
Title: Re: lossyWAV 1.5.0 Development
Post by: punkrockdude on 2016-03-03 08:01:31
Might be what I have reported before and that is to change
Code: [Select]
-o%d
to
Code: [Select]
-o %d
. Please let me know if that worked.
Title: Re: lossyWAV 1.5.0 Development
Post by: sundance on 2016-03-03 08:57:19
"Hybrid" adaptive noise shaping (and the other changes in 1.4.1j):
Is there some (more detailled) information on what they do to read other than the change log?
Title: Re: lossyWAV 1.5.0 Development
Post by: sundance on 2016-03-03 12:02:20
And, a minor cosmetic "glitch":
There's a "\n" missing in the long help text (-L) at the shaping section (before "n, nowarp"):
Code: [Select]
-s, --shaping        modify settings for noise shaping used in bit-removal:
       a, altfilter  enable alternative adaptive shaping filter method.
       c, cubic      enable cubic interpolation when defining filter shape
       e, extra      additional white noise to add during creation of filter
       f, fixed      disable adaptive noise shaping (use fixed shaping)
       h, hybrid     enable hybrid alternative to default adaptive noise shaping
                     method. Uses all available calculated analyses to create
                     the desired noise filter shape rather than only those for
                     1.5ms and 20ms FFT analyses.       n, nowarp     disable warped noise shaping (use linear frequency shaping)
Title: Re: lossyWAV 1.5.0 Development
Post by: Nick.C on 2016-03-03 19:15:38
Thanks for the cosmetic bug report. :D

I'll try to come up with a better description of the difference that the Hybrid shaping method brings soon.
Title: Re: lossyWAV 1.5.0 Development
Post by: duelle on 2016-03-03 23:51:24
Might be what I have reported before and that is to change
Code: [Select]
-o%d
to
Code: [Select]
-o %d
. Please let me know if that worked.

Now it fails with code 1 (0x00000001) instead of code 0.
Title: Re: lossyWAV 1.5.0 Development
Post by: sundance on 2016-03-04 09:01:14
@Nick:
Quote
Thanks for the cosmetic bug report. :D
I'll try to come up with a better description of the difference that the Hybrid shaping method brings soon.
No sweat. It's truly amazing how you always come up with improvements for lossyWAV (already being an excellent audio compressor with outstanding sound quality, and the latest speed improvements are always welcome).
Thanks a lot for your continued efforts!
Title: Re: lossyWAV 1.5.0 Development
Post by: duelle on 2016-03-04 15:48:42
https://hydrogenaud.io/index.php/topic,89368.msg766061.html#msg766061

Okay, got it working using this method. Next question: how do I get it to downsample to 44100Hz automatically?
Title: Re: lossyWAV 1.5.0 Development
Post by: GeSomeone on 2016-03-05 11:38:58
downsample to 44100Hz automatically?
As this has noting to do with the lossywav topic, it would be better to use the search function or open a new topic in the foobar2000 -> general section.
Hint: processing -> DSP -> resampler
Title: Re: lossyWAV 1.5.0 Development
Post by: duelle on 2016-03-05 16:21:46
downsample to 44100Hz automatically?
As this has noting to do with the lossywav topic, it would be better to use the search function or open a new topic in the foobar2000 -> general section.
Hint: processing -> DSP -> resampler

Yep, figured that out with a quick search. Very impressed with lossyWAV so far.
Title: Re: lossyWAV 1.5.0 Development
Post by: sundance on 2016-04-26 07:25:54
@Nick:
Code: [Select]
Expiry: n.b. This beta version expires on 26th of April, 2016
So far, obviously no one had/reported issues with v1.41j.
Wouldn't it make sense to drop the "drop-dead date" for a final version 1.42?
Title: Re: lossyWAV 1.5.0 Development
Post by: Nick.C on 2016-04-26 12:59:08
That sounds like a plan.

I'll release one more beta (because of the current drop dead date) and then start final code tidy up prior to release of 1.4.2 in due course.

.... and done (well, the beta, anyway).

lossyWAV beta 1.4.1k attached to post #1 in this thread.
Title: Re: lossyWAV 1.5.0 Development
Post by: Nick.C on 2016-04-26 13:08:22
Hint: processing -> DSP -> resampler

Actually, lossyWAV should be the final step - otherwise the carefully zeroed lsbs will probably become non-zero and the compression advantage (using the wasted-bits feature) would be lost.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: sundance on 2016-04-27 07:52:52
Although the zip file's name is "lossyWAV_beta_1.4.1jk.zip", there's just "k" inside...  ;)
Thanks for the update and the positive outlook for a "non-drop-dead" version - and maybe it'll come "(...) with a better description of the difference that the Hybrid shaping method brings..."
Thank you very much Nick!
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: adamdea on 2016-04-27 10:43:43
I have a query. I have been playing with lossywav to compare what could be done with it to produce an equivalent to  MQA ie essentially lossy 24/96. I can see that lossywav would compare favourably in terms of the size of files. Anyway I noticed that the settings only allow analysis up to 20,000 kHz. Is there any way to allow analysis higher since i know higher bitrates are supported. I tried creating a high pass filltered version of the file (>24KHz) and noted that lossywav produces exactly zero change since it analyses zero noise.

I do appreciate that doing anything over 20kHz is probably pointless since no one can hear over that frequency etc etc . But if we are allowed to put that to one side, and noting that higher sample rates are supported. Would it be possible to tweak the parameters to allow analysis up to 48 KHz and/or analsis only over 22/24kHz?

 If we assume that there is a market for compressed 24/96 for streaming, it would be nice if this could done in an open source way involving pure LPCM.

I have another query which was that when apply lossyway to a full range 24 bit recording and looking at the correction file I got a big hump in frequency  response   right in the most sensitive audible range and at around -100db. Maybe low enough in level not o be a problem, but this surprised me as I had expected there to be the least energy in the correction file in the most audible places. Have I misread this (very far from expert obvs)
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Wombat on 2016-04-27 19:19:10
Seems MQA does a good job already with creating a need.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Nick.C on 2016-04-27 20:59:29
The frequency limit for analysis is the upper bound of the frequency band within which the lowest fft result bin is sought - this level is then used to determine how many bits can be removed (before the added noise exceeds a particular level).

Why would anyone want the low point in the signal's frequency distribution to be sought outwith the limits of human hearing?

Does the spectral shape of the correction file resemble that of the original? If so then the adaptive shaping would seem to be working.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: adamdea on 2016-04-28 01:19:28
The frequency limit for analysis is the upper bound of the frequency band within which the lowest fft result bin is sought - this level is then used to determine how many bits can be removed (before the added noise exceeds a particular level).

Why would anyone want the low point in the signal's frequency distribution to be sought outwith the limits of human hearing?

Does the spectral shape of the correction file resemble that of the original? If so then the adaptive shaping would seem to be working.
Sorry if i am being obtuse here. Obviously I understand that on a rational bit reduction program based on audibility, the entire band over 22khz (arguably lower) would removed. But if we can be allowed to go with the idea that one wants to allow the noise above 22Khz to be more efficiently packed as we would do in the sub 22Khz region, don;t we need to analyse the region over 22khz. I was hoping to work out a way of looking at the high passed file in isolation (so that we could apply different rules above and blow 22Khz.) If I try to do this at present I get no effect at all presumably because lossy way determines that there is no noise in the range it analyses.

ON the second part, perhaps i have misunderstood the meaning of the correction files spectrum. I had assumed that the spectrum of the correction file would equate to the spectrum of the noise which had been added to the original signal wav to get to the lossywav- and that one would hope that it would have least energy in the audible range (the correction file not the signal). Have I got this the wrong way round?
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: 2Bdecided on 2016-04-28 08:06:09
I think it's reasonable to allow a user to set any arbitrary frequency limit for the analysis if they wish. Without shaping it will dramatically reduce the number of bits that can be removed. With shaping, the reduction will not be quite so dramatic, but still significant. LossyWAV isn't removing anything above 20kHz (or whatever limit you set) - it's just swamping it in noise if the content above 20kHz is at a much lower level than the content below 20kHz (which is usually the case).

You can trick lossyWAV in to doing what you want (though it won't quite to the "proper" analysis, so don't use this for encoding, just to get a feel for what might happen). Take your 96kHz audio in to an audio editor (or other program) which lets you change the sample rate specified in the WAVE header without resampling the audio. Just say that it's 48kHz or 44.1kHz or 32kHz (this operation should be instant by the way - if you see a progress bar, it's resampling, which you don't want!), and re-save it. If you play it, it should  be at half speed. Now send the result through lossyWAV. If you went for 48kHz sampling, it will analyse up to 40kHz (thinking it's 20kHz). If you went for 32kHz sampling, it will analyse everything. See what happens. You can go back in to the audio editor and put the sample rate flag back to 96kHz to get a usable file if you want. Note that the analysis calculations within the real audio band will be "wrong" because you've forced lossyWAV to misinterpret the frequencies. Hence you might in theory introduce audible problems with this approach. It's just so you can have a play and see the kind of bitrates you would get if this was done "properly".

Cheers,
David.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: adamdea on 2016-04-28 15:18:54
. Note that the analysis calculations within the real audio band will be "wrong" because you've forced lossyWAV to misinterpret the frequencies. Hence you might in theory introduce audible problems with this approach. It's just so you can have a play and see the kind of bitrates you would get if this was done "properly".

Cheers,
David.
Thanks David. If I am using a  file high passed at 24khz or so before playing at half speed, then will the result be correct? At least there won't be an audioband to mess up.

Sorry if these questions seem dumb, or the task futile, but it seems to me that if as MQA presumes, there is a market fro streaming 24/96 files, then lossywav really could provide an open source way of doing it which should work much better with subsequent eqing than the somewhat opaque MQA process, and should work for anyone with a 24/96 dac.

What I am ideally tryig to work out is whether the file could be made to compress 24/96 to somethign like ordinary 16/44 (or 24/44)plus a variable bit rate version of the next octave with just enough snr to preserve whatver actual signal there is in that band. The end product may just be very well compressed 16/96 or 24/96. or perhaps a basic 16/44 file with another file which can be mixed with it.

My major concern is to work out how to get lossywav to analyse that addtional octave and apply noise based on the characteristic of that octave not the audible range.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Wombat on 2016-04-28 16:07:11
I wonder if even a more predictable way for the filesize could be to simple use 16bit 96kHz with a noise shaped dither. I did no test for that but played with Shibatas SSRC, shape 2 and 16bit 88.2kHz. The files seem to be smaller as MQA'd.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Nick.C on 2016-04-28 22:16:37
My major concern is to work out how to get lossywav to analyse that addtional octave and apply noise based on the characteristic of that octave not the audible range.

I'll produce a new beta with more flexibility applied to the "-l, --limit" parameter. Should be posted tomorrow morning.

I'll also see about adding a new adaptive shaping sub-method that will attempt to significantly reduce added noise in the audible range. Can't promise that for tomorrow though.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Nick.C on 2016-04-29 11:08:01
lossyWAV beta 1.4.1m attached to post #1 in this thread.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: adamdea on 2016-04-29 17:22:38
Wow thanks very much
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Nick.C on 2016-04-29 17:27:06
No problem..... :)
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: alter4 on 2016-04-29 20:57:29
Dear HA folks, I see  sundance asked about  "...a better description of the difference that the Hybrid shaping method brings..." I am interested in the understanding of this thing too. Could somebody bring this?
Thanks.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Nick.C on 2016-04-30 09:22:44
Could somebody bring this?

Only me, I'm afraid (until I publish the source when 1.4.2 is released)....

Basically the existing adaptive noise shaping method creates a "desired noise shape" from the FFT results of the 1.5msec and 20msec FFT analyses, using an increasing proportion of one / decreasing proportion of the other as frequency increases.

What the hybrid method does is to take into account FFT results from all analysis lengths carried out - and adds them together (there is some stretching involved for all but the longest FFT).  The order in which additional FFTs are introduced (by the -a, --analyses parameter) has been reversed so that the 10msec FFT is the first additional one added - this seems to improve the shape of the noise introduced by the adaptive shaping.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: alter4 on 2016-04-30 09:44:00
Thank you Nick.C!
If I use 1,4,1m with command line  '--quality high' Is that option still the best recommended setting for this level of quality or I can improve the quality by adding force hybrid shaping to the command line? 
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: 2Bdecided on 2016-04-30 20:43:32
If I am using a  file high passed at 24khz or so before playing at half speed, then will the result be correct? At least there won't be an audioband to mess up.
Your highpassed file has little or nothing in the audioband, hence the noise floor in the audioband is exceptionally low. Hence lossyWAV probably won't remove any bits, as it will attempt to preserve that artificially low noise floor. Hence highpassing the file isn't going to tell you anything useful about the ultrasonics because the very act of highpassing the audio stops lossyWAV from doing anything.

Quote
Sorry if these questions seem dumb, or the task futile, but it seems to me that if as MQA presumes, there is a market fro streaming 24/96 files, then lossywav really could provide an open source way of doing it which should work much better with subsequent eqing than the somewhat opaque MQA process, and should work for anyone with a 24/96 dac.
Neither dumb nor futile. You can certainly use lossyWAV to preserve 96kHz audio at lower bitrates without introducing the 22.05Hz filtering that the inventors of MQA believe is so terrible.

Be careful if you try to copy some of the other ideas from MQA though - there are patents. I haven't read them carefully enough to give an opinion, and IANAL.

Cheers,
David.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: alter4 on 2016-05-07 14:37:13
If I use 1,4,1m with command line  '--quality high' Is that option still the best recommended setting for this level of quality or I can improve the quality by adding force hybrid shaping to the command line? 
Nobody answered so I made comparison of 2 sines signal with " --quality standard" vs  "--quality standard -s h" settings.
The result is below (hudrid, original and pure standard)
http://imgur.com/a/O5eX9
Of course the noise in all cases is inaudible but pure standard looks better. I stick to pure standard settings.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: GeSomeone on 2016-06-30 12:24:05
I had some trouble using lossyWav lately, turns out 1.4.1m has expired.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Fairy on 2016-06-30 13:44:42
I had some trouble using lossyWav lately, turns out 1.4.1m has expired.

Nick has been exactly on time releasing a new beta everytime. Wonder what's up.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Nick.C on 2016-06-30 14:02:31
lossyWAV beta 1.4.1n attached to post #1 in this thread.

(apologies for the late arrival)
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: corrideat on 2016-08-09 15:11:35
Hi,

I've found the idea of this wave processor to be quite interesting, and yesterday I completed porting the code to probably most modern POSIX systems (i.e., Linux, *BSD, MacOS X, AIX, etc.) I've tested it on Linux and FreeBSD and things seem to work (I haven't tried all the options, though, so there may be bugs.) It's also possible I accidentally broke the Windows version.

This is the summary of changes:
* Replaced all native Windows calls with their POSIX counterparts (used pre-processor blocks to write OS-specific code)
   - Also made some minor portability changes, like calling main int main(int, char**) instead of int main(uint32_t, char**)
   - Note: MinGW and/or Cygwin support may (or may not) be broken, because the Win32 API is preferred over POSIX. I'm not sure how these subsystems like non-POSIX code.
* Added myself as an author to this relase (to comply with GPL requirements)
   - I've called this release of mine 1.4.2 (we can talk about versioning so that people don't get confused)
   - Feel free to implement my changes into your next release (I can provide a diff file), then we don't have two separate branches
* Converted the files to UTF-8 for better portability
* Fixed some things apparently were bugs
   - For example, some attributes in nSGNS.h (lines 66-68) didn't receive their alignment attribute.
   - Also, in nWav.cpp, lines 1265 and 1300, I fixed a comparison from if (!foo == bar) to if (foo != bar). The original form gets evaluated as if ((!foo) == bar), and since !foo is always 0 or 1 and bar is probably neither, the code never gets executed. The exact code was "if (!thisRIFF.File.Read(thisRIFF, (char*) thisMapRecord->DATA, thisChunkSize) == thisChunkSize)"

The code is available on GitHub[1] and attached to this post. I'm thinking about rewriting the entire utility in C, designing it for portability from the beginning and incorporating OpenCL or CUDA support for FFT, bit removal and noise shaping. It should certainly speed it up. Should I begin this project, I'll make sure to share it on a new thread.

[1] https://github.com/corrideat/lossywav
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: 2012 on 2016-08-09 20:55:34
Hi,

I've found the idea of this wave processor to be quite interesting, and yesterday I completed porting the code to probably most modern POSIX systems (i.e., Linux, *BSD, MacOS X, AIX, etc.) I've tested it on Linux and FreeBSD and things seem to work (I haven't tried all the options, though, so there may be bugs.) It's also possible I accidentally broke the Windows version.


https://hydrogenaud.io/index.php/topic,107774.msg884548.html

Quote
I'm thinking about rewriting the entire utility in C, designing it for portability from the beginning and incorporating OpenCL or CUDA support for FFT, bit removal and noise shaping. It should certainly speed it up.

https://hydrogenaud.io/index.php/topic,107081.msg897190.html#msg897190
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Triza on 2016-08-13 08:33:48
Hello Nick and Corrideat,

Where is the canonical repository for the source code. I see people starting various repositories

https://github.com/MoSal/lossywav-for-posix
https://github.com/corrideat/lossywav

Not obvious which version they started their copy. I am not sure where I could get the latest source, either.

Cheers,

Triza
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Triza on 2016-08-13 11:23:41
I cannot edit my former post, but I think I concluded that there is no official source repository. Perhaps people spring up those repos based on the source at https://hydrogenaud.io/index.php/topic,107081.msg

Nick,

If so, would you consider hosting the source on GitHub or somewhere. I am not saying it is top priority, but getting everyone who wishes to fix the Linux compatibility (or other issues) to converge on the same repo would be good. Then you could merge their work into the main branch time to time. I am also on Linux exclusively, and a canonical repo would be great.

Thx so much for developing and looking after LossyWAV.

Triza
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Nick.C on 2016-08-13 14:06:45
@corrideat: Your version does not sit within the existing 1.4.x numbering system as it is based on the 1.4.0 source - also, 1.4.2 is already "taken".

@2012: Your previous efforts are appreciated.

@Triza: Good point. When I release 1.4.2, I will create a github repository (or use the existing one created by rtollert some time ago).
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Musique-Rabbit on 2016-08-31 12:33:23
@Nick.C: my LossyWAV is waiting for the next incarnation...
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: improb on 2016-09-01 08:59:19
Looking forward to the new version! Also, a question: my primary use of lossyWAV is to transcode podcasts, downmix to mono and src to 32k. Aside from --limit 14512, are there any parameter changes you would recommend for this purpose?
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Nick.C on 2016-09-01 09:43:30
@Nick.C: my LossyWAV is waiting for the next incarnation...

Apologies (I seem to be doing that rather a lot recently).

lossyWAV beta 1.4.1o attached to post #1 in this thread.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Musique-Rabbit on 2016-09-01 15:47:52
My lossyWAV is alive, again!

Thanks, Nick.C!
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Nick.C on 2016-09-15 10:16:52
lossyWAV 1.4.2 released here (https://hydrogenaud.io/index.php/topic,112649).
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: falloutphil on 2016-11-05 16:00:56
Quick question - is it possible and/or has anyone every attempted to combine lossyFlac and correction file without going back to WAV format?

I recognise (and am considering) writing something that will combine the 2 decoded PCM streams (lossy + correction) and return a single lossless FLAC file.  (at the moment I only know of scripts that do this by de-FLACing each file to temp directory and the resulting files are then pased to lossyWAV so that the merge wav can be piped to the standard Flac encoder rather than doing everything, in memory, as one compiled program).

However it struct me that not only I could I do this all in memory, but perhaps I might be able to *combine directly* the 2 FLAC files without going via PCM and back to FLAC, this is could be quicker.

Note this would be for time-sensative operations like transcoding so that I could easily play music back losslessly on-the-fly with a single program; thus I wouldn't care so much if combining the 2 FLAC files resulted in a larger but valid FLAC representation than converting both back to PCM first as it would only exist for the life of the playback.

One last question - do any audio players support playback of both lossy and correction at the same time.  My understanding is that they wouldn't need to explicitly support lossyWav - just be configurable to play both Flac files in exact synchrony?

Thanks!

I'm guessing this isn't
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: punkrockdude on 2017-10-26 17:21:38
With DeaDBeeF's author I got lossywav to work in DeaDBeeF. I use the following command:
lossywav - -q high --linkchannels -s f -m --maxclips 0 -w --bitdist --silent --stdout | flac - -b 512 -5 -f -o %o --ignore-chunk-sizes

I use Arch based distro and compiled lossywav from their AUR repo. I guess you have to change the quality settings according what you want to use. One problem though is that the logfile is created in /home/username/ and not in for example /home/username/music/targetfolder/ where the audio files end up.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: theselector on 2018-01-07 13:46:22
hi to everyone. i compared lossywav to wavpack hybrid lossy. I compared this to methods using audacity(inverting packed track and mix with original). And wavpack is much better in all songs examples - have less noise after packing. So i recommend to use wavpack hybrid mode. Hope this will be usefull for someone. Thank you
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Fairy on 2018-01-10 10:34:19
hi to everyone. i compared lossywav to wavpack hybrid lossy. I compared this to methods using audacity(inverting packed track and mix with original). And wavpack is much better in all songs examples - have less noise after packing. So i recommend to use wavpack hybrid mode. Hope this will be usefull for someone. Thank you

Making statements without any proof is a violation of the #TOS here.

If you want to make such a claim, write some extensive information about you test procedures, parameters and a whole lot more and provide double blind test results.

You're claiming something that is nonsense in the first place to my opinion.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: CitizenInsomniac on 2018-07-06 18:52:52
Has anyone encountered any issues with LossyWAV 1.4.2 handling 96 kHz 5.1 (6-channel) 24-bit WAV files? It gives me a bunch of errors that look like this:

Too much WAV information before 'data' chunk!
RIFF; 46464952-0000-0000-0000-000000000000; 00000000


And then it crashes.

Is there something I can do to the WAV files (at a file container level) to work around this problem? I'd prefer not to have to resample or dither the PCM just to make LossyWAV work.

Here's a MediaInfo snapshot of the WAV source I'm using:
Code: [Select]
Format                                   : Wave
File size                                : 432 MiB
Duration                                 : 4 min 22 s
Overall bit rate mode                    : Constant
Overall bit rate                         : 13.8 Mb/s
Writing application                      : Lavf58.17.100

Audio
Format                                   : PCM
Format settings                          : Little / Signed
Codec ID                                 : 00000001-0000-0010-8000-00AA00389B71
Duration                                 : 4 min 22 s
Bit rate mode                            : Constant
Bit rate                                 : 13.8 Mb/s
Channel(s)                               : 6 channels
Channel positions                        : Front: L C R, Side: L R, LFE
Sampling rate                            : 96.0 kHz
Bit depth                                : 24 bits
Stream size                              : 432 MiB (100%)
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: [JAZ] on 2018-07-06 20:30:00
Maybe it is having a problem detecting the format correctly.

I am guessing that you might have a Riff64 file that might not be exactly like what lossywav expects. You could try converting it to riff32, given that the file size is less than 2GB.

If you use audacity, you could try file->export -> export as wav, other uncompressed formats, and there waveex (microsoft) and signed 24bit PCM.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: kode54 on 2018-07-07 03:41:26
Looks like it was exported as WaveFormatExtensible instead of WaveFormatEx, probably to support the speaker coverage bits.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: shadowking on 2018-07-07 06:45:07
hi to everyone. i compared lossywav to wavpack hybrid lossy. I compared this to methods using audacity(inverting packed track and mix with original). And wavpack is much better in all songs examples - have less noise after packing. So i recommend to use wavpack hybrid mode. Hope this will be usefull for someone. Thank you

Making statements without any proof is a violation of the #TOS here.

If you want to make such a claim, write some extensive information about you test procedures, parameters and a whole lot more and provide double blind test results.

You're claiming something that is nonsense in the first place to my opinion.

It could be true. Wapack at same bitrate is better than lossywav with objectively less noise .  Lossyway noise moves in 6db steps while wavpack moves infinite steps from what I read in the past. OTOH Wavpack doesn't have a yet a true quality mode while lossywav does. This also might not have any impact if comparing strong settings like lossyway --extreme to wavpack -b550x4 .. wavpack is also expected to be 100% transparent and offering better quality [objective].  At more moderate bitrates (400k)  subjectively , Lossywav may have the advantage in very rare cases due to the quality mode . At lower rates like 250k wavpack may have a general advantage too .
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: CitizenInsomniac on 2020-01-21 07:49:06
Has anyone encountered any issues with LossyWAV 1.4.2 handling 96 kHz 5.1 (6-channel) 24-bit WAV files? It gives me a bunch of errors that look like this:
Too much WAV information before 'data' chunk!
RIFF; 46464952-0000-0000-0000-000000000000; 00000000


In case anyone runs into the same issue... Here's the workaround: just use FFmpeg to remux your WAV files with channel map set to 5.1 instead of 5.1(side) which is the FFmpeg default.

For example:
Code: [Select]
ffmpeg -y -i input_96khz_24b.wav -acodec pcm_s24le -af channelmap=channel_layout=5.1 output.wav
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Nick.C on 2020-01-22 10:08:02
Glad that you found a solution to the issue.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: magicgoose on 2020-01-22 10:34:45
Is it possible to adjust block size? (if no, what's your prediction of difficulty to add it? I assume it's not just 1 variable, many things probably depend on it, etc)

(why: I was thinking of using LossyWav to reduce size of some high resolution (24 bit) records for long term storage/transcoding in a way that keeps them strictly not worse than a simple conversion to 16 bits per sample would do, while also keeping some extra precision only in quieter sections. AFAIK lossywav can be commanded to do this using parameters --dynamic and --static, but I found that in this mode of operation, the result compresses worse if FLAC is set to use 512 block size (in comparison to default FLAC settings), so it looks like this combination can work better with a different block size in lossywav.)
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Nick.C on 2020-01-23 09:31:38
Internally, block size is determined by sample-rate, e.g. 512 samples for 44.1/48 kHz; 1024 samples for 88.2/96kHz; etc..

FLAC blocksize can be varied independently of lossyWAV processing block-size.

Recently I have been using foobar2000 to convert 44.1/16 FLAC to lossyFLAC - setting foobar2000 to output 24-bit as input to lossyWAV (and scaling by 0.5 to give the ANS "room" to work).

--static and --dynamic set the minimum-bits-to-keep for each sample from a fixed datum (--static) or a dynamic datum based on block noise (--dynamic).
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: magicgoose on 2020-01-23 10:35:02
Internally, block size is determined by sample-rate, e.g. 512 samples for 44.1/48 kHz; 1024 samples for 88.2/96kHz; etc..
Yes I've read about this; I was asking if it's possible to alter this to let LossyWAV use, for example, block size of 4096 samples for 44.1 kHz.

Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Max9000 on 2020-09-19 05:44:04
Would this also work for MP3's? 
I ask because VBR MP3's could do either nicer or smaller if the sample rate (bitdepth) is reduced/optimized before encoding. 
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: lvqcl on 2020-09-19 15:08:40
It won't work for MP3.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Nick.C on 2020-09-19 16:31:49
It won't work for MP3.
Indeed.

@Max9000The method used by lossyWAV doesn't work with MP3 - and lossyWAV isn't competitive in terms of bitrate with MP3 either.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Max9000 on 2020-09-20 05:48:23
Hi Nick.  And thanks!

I asked because the barrier to good small mp3 files was CD 44100 sample-rate spec (harms/exhausts small-rate mp3's); but, high quality small files can be had with 32000 sample rate, so long as it wasn't done with the mp3 codec's inbuilt fast-n-dirty resampler.   Foobar's PPHS set to Ultra will do much better than the codec's inbuilt resampler.

The trouble with non-adaptive sample rate reduction is noise floor (like a slower LP or tape). 

So, I'm curious about PPHS-ultra@32000 > LossyWAV > WavPack lossy@460 (also quality max) > GXlame -V30.

Basically, if a LAME variant can't toss the extra bits, then an interstage of WavPack might get it.  I'm just not sure if I got the chain right.  Where is the best spot for the 32000 conversion? 

P.S.  Application is internet radio. 
Could be really useful if:  Archive quality at smaller file size > also results in smaller production bandwidth consumption.  Is that feasible? 
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: lvqcl on 2020-09-20 13:50:57
The trouble with non-adaptive sample rate reduction is noise floor (like a slower LP or tape). 

I don't fully understand your idea, but LossyWAV increases noise floor, not decreases it. So this --
So, I'm curious about PPHS-ultra@32000 > LossyWAV > WavPack lossy@460 (also quality max) > GXlame -V30.
-- makes zero sense.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Max9000 on 2020-09-20 18:06:36
It would make more sense if I could use LossyWAV as an opportunistic resampler 44100 (or any) input, to 32000 (or lower) output. 
That would actually make smaller WAV files which could be used for smaller AAC, smaller MP3, etc...

Perhaps it is a prospective cool new feature for LossyWAV 1.5.0?
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Rollin on 2020-09-21 06:57:04
The trouble with non-adaptive sample rate reduction is noise floor
Aren't you confusing downsampling with bit depth reduction?
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Nick.C on 2020-09-21 10:27:55
The trouble with non-adaptive sample rate reduction is noise floor
Aren't you confusing downsampling with bit depth reduction?
Indeed - lossyWAV does not resample the audio.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Max9000 on 2020-09-21 17:19:08
Aren't you confusing downsampling with bit depth reduction?
I did.  Sorry about that! 

Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Brent on 2021-09-30 13:02:40
Wanted to report on the savings on my FLAC library.

I used the POSIX port [1], as I am on Linux. Compiled flawlessly at first try! I converted my lib to standard losswav and standard FLAC compression. Used the following line:

Code: [Select]
flac -d "$i" --stdout --silent|lossywav - --stdout --quality standard --stdinname -- |flac - -b 512 -o "${i%.*}.lossy.flac" --silent &&  metaflac --export-tags-to=- "$i" | metaflac --import-tags-from=- "${i%.*}.lossy.flac"

Savings: 279GB -> 125GB or about a 60% reduction. Not bad! Thanks to all involved!

[1] https://github.com/MoSal/lossywav-for-posix
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Brent on 2021-09-30 13:03:38
Also, how's1.4.2/1.5.0 dev going? Things look a bit stalled ;)
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Nick.C on 2021-09-30 22:06:14
Also, how's1.4.2/1.5.0 dev going? Things look a bit stalled ;)
It was released, here: https://hydrogenaud.io/index.php?topic=112649.0 - just over five years ago.

It's not under development - as I haven't identified any required additions or modifications.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: synclagz on 2021-10-01 08:53:49
Also, how's1.4.2/1.5.0 dev going? Things look a bit stalled ;)
It was released, here: https://hydrogenaud.io/index.php?topic=112649.0 - just over five years ago.

It's not under development - as I haven't identified any required additions or modifications.

Hi,

I was wondering... Is it safe to turn off noise shaping (-s o) at higher settings (standard and higher /quality 2.5 and up)?
I've noticed huge increase in encoding speed and I didn't find issues on few critical samples that I've tested (in short: I've got fast encoding speed without obvious quality loss).
What is worst case scenario on disabled noise shaping at higher bitrate? I'm considering to use lossywav/flac at 450-480k.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: amariami on 2021-10-11 11:27:42
What is the worst-case scenario on disabled noise shaping at a higher bitrate? I'm considering using lossywav/flac at 450-480k.
dither/noise-shaping standing for truncation distortion noise artifacts. if you hear that you should turn on dither/noise shaping
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: punkrockdude on 2022-08-19 18:48:16
If you have issues compiling LossyWAV for Linux using the earlier github repository you can try the following: https://github.com/Sound-Linux-More/lossywav-for-linux

This github repository compiles (x86_64) successfully on Arch Linux.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Eurobeat_fan on 2023-01-10 06:44:02
I find it interesting how it struggles when there's super low low-pass filter in music. For example lossyWav can't compress Diablo Swing Orchestra - Swagger And Stroll Down The Rabbit Hole album effectively - I get 700-800 kbps at standard preset. The reason seems to be the terrible sound on the album that is lowpassed at 13 khz.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Nick.C on 2023-01-11 20:46:26
The reason seems to be the terrible sound on the album that is lowpassed at 13 khz.
In this case you could use the "--limit <n>" option to reduce the upper frequency limit that the analysis uses. The minimum allowed value is 12.5kHz.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: doccolinni on 2023-01-13 05:27:35
This seems like something that could be circumvented by taking noise shaping into account during the analysis phase (if noise shaping is enabled, of course), because it seems as if the analysis assumes flat (white) noise.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Nick.C on 2023-06-21 20:42:07
Please find attached a new beta release of lossyWAV. Attachment removed as expired.

lossyWAV beta 1.4.3a, 21/06/2023 (expires 31/07/2023)

General Comment
From experience using lossyWAV with adaptive shaping enabled to process 16-bit audio (primarily from CDs), using the foobar2000 commandline encoder to process FLAC to lossyFLAC, setting the converter to "lossless (or hybrid)" and selecting 24-bit in the "Highest BPS mode supported" dropdown, setting "Output bit depth" to 24-bit in the Converter Setup dialog dropdown, then adding "--scale 0.5" to the lossyWAV element of the commandline encoder settings (to losslessly scale the 16-bit-sample-in-a-24-bit-container) will usually result in the output files being smaller than they would otherwise have been, up to c.1% smaller at lower quality presets. I attribute this to giving the adaptive shaping method "room for activities" by allowing samples to exceed what would otherwise have been full scale in the unscaled 16-bit audio.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Make_it_possible on 2023-08-05 19:54:39
LossyWAV is fantastic.
I found LossyWAV to be excellent at compressing 24Bit 96KHz stereo LPCM to 640~768Kbps LossyFLAC. This is a reasonable bitrate and there are no phase problems from SRC. I tried to test LossyWAV 96KHz SINAD. it was about 128~144dB from 1KHz to 20KHz Sine signals at a volume of -12dB~0dB, and the IMD was satisfactory. It outperforms AAC 96KHz at the same bit rate, and Ogg 96KHz at 512Kbps.

But there's an idea. Is it possible to use blue noise or violet noise as a noise shaping dithering tool to reduce the bit depth for 96KHz PCM like the wavpack? In this way the SNR in the auditory sensitive frequency domain can be further improved.

Thanks again for your excellent work.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Nick.C on 2023-08-05 20:04:19
I'll take a look at implementing blue and violet noise shaping options for testing in the next beta version.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Nick.C on 2023-08-06 14:16:42
Please find attached a new beta release of lossyWAV.

lossyWAV beta 1.4.3b, 06/08/2023 (expires 30/09/2023)
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Make_it_possible on 2023-08-06 15:16:36
I did a 96KHz lossy compression SNR comparison based on cmpute's project: github.com/cmpute/audio-codec-benchmark.
Based on previous experience, three noise shaping options were chosen as representative: hybrid, fixed, and off.

The test-audio files tested combined a wide range of music genres and a variety of mastering styles, and I think that in the Noise-Rock, LossyWAV performed the best.

https://imgur.com/a/aOOldgi
(For detailed data, please see the annex.)

LossyWAV (-q 4~10 -a 3 -s h/f/o -l 16000 )+ FLAC (-5 -b 1024) consistently outperforms common codec ( AAC (QAAC, NeroAAC, FDK-AAC), Ogg Vorbis, and WMA PRO) in terms of SNR/Spectrogram-error and A-weighted SNR/Spectrogram-error when the bit rates are approximated. But achieving a bit rate below 512Kbps with 96KHz LossyFLAC is difficult, and at that point, while the SNR may be slightly higher than AAC, the audible advantage is lost. And it's not listed in the charts, but I compared it to commercial lossy encoders such as DTS 24/96 768Kbps & 1509Kbps, which actually doesn't perform as well as LossyFLAC in terms of listening and test data.

Among them, the LossyWAV with fixed 16KHz noise shaping has a very good SNR, and my actual ABX comparisons also felt less lossy, sounding more like a lossless audio with dithering.
However, the fixed noise shaping has worse compression ratio than the hybrid shaping for the same quality parameters.
If noise shaping is turned off, the difference to Hybrid mode is actually not that great aurally, but the SNR ratings will be better and the encoding will be fast. But down below q 1, hybrid shaping is audibly more comfortable.

https://imgur.com/a/OnHuDWN
more info here:
https://imgur.com/a/FcxZwRJ

I also wrote a SINAD and RMSE test, and the 24Bit LossyWAV has a SINAD performance that exceeds the 16Bit LPCM.
This performance is very impressive, nowadays narrow dynamic range pop music is more important to consider the performance of lossy codec at -0dB than wide dynamic range classical music.

Aurally, fixed noise shaping is better for high bitrates, just as wavpack's purple-like noise shaping doesn't work well at low bitrates lossy mode.
However, I tested it a few years ago. FLAC compresses purple/blue noise at the same level more efficiently than high-pass dithering noise. It seems that this may be the reason why wavpack lossy has a lower bitrate but approximating A-weighted SNR.

But considering the performance requirements and compatibility of decoding FLAC -5-b 1024.
There is no doubt that LossyFLAC has a reliable and reasonable 96KHz lossy compression performance.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: magicgoose on 2023-08-06 17:15:53
Using this kind of compression on higher-than-necessary sampling rates (like 96k) makes little sense to me.
Pretty sure it will be more efficient to downsample to something closer to (2 * max audible frequency) before any lossy compression.
Otherwise the result has to waste space on stuff that can't be heard, while adding some distortion to the useful frequency range, and providing no way to discard the unneeded info without more distortion to the useful range.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Make_it_possible on 2023-08-07 17:07:13
Lossy audio at high sample rates actually has its place, unlike the case of active noise cancelling headphones where the distortion performance of the amplifier is more important than the high-resolution encoding.

Quite a few mastering, the Hi-Res version retains more dynamic range than the CD/WEB version (especially in Japan), and this is why directly lossy compressing the Hi-Res version makes more sense than compressing CD/WEB 16/44.1.

If a minimum phase 44.1K resampler is used for the 96K version, the sample point at the -0.1dB level may be grossly out of peak, causing clipping in 16Bit int. It's not as lossless when it has to be limited after resampling.

Another reason is that LossyFLAC 96KHz is also acceptable at around 570Kbps bitrate in some setting, and there is no significant bitrate increase over LossyFLAC 44.1KHz at around 480Kbps (-q 2.0 to 5.0).
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Make_it_possible on 2023-08-07 19:03:16
I tested the theoretical performance of LossyWAV 1.4.3b (44.1KHz & 96KHz) with different noise shaping modes with parameter: -q -5/-2/0/2/4/5/6/7/8/9/10.

For 44.1KHz,  common parameters: -a 4 -l 15848 --maxclips 2.

(https://i.imgur.com/aObkQ1U.png)

For 96KHz,  common parameters: -a 3 -l 16000 --maxclips 2.

(https://i.imgur.com/gGlykKt.png)

And different noise shaping behaves differently at the two sample rates, with 88.2K/96K having more room for noise shaping, and 44.1K/48K not so much.
But my initial feeling is that Weighted 2 sounds great even in -q 0 (44.1KHz).
I will try to audition various music genres using studio speakers, wired headphones, mobile bluetooth amplifier + wired in-ear headphones (LDAC/aptx HD codec).
The performance of the lossy encoding after lossy Bluetooth transmission is also a part to be examined now.
Some noise shaping may have excellent SNR, but after the distortion of the playback system, it may become worse.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: magicgoose on 2023-08-07 21:55:54
Lossy audio at high sample rates actually has its place, unlike the case of active noise cancelling headphones where the distortion performance of the amplifier is more important than the high-resolution encoding.
Amplifier is almost always more important.

Quite a few mastering, the Hi-Res version retains more dynamic range than the CD/WEB version (especially in Japan), and this is why directly lossy compressing the Hi-Res version makes more sense than compressing CD/WEB 16/44.1.
Is it so high as to make 16/44.1 unsuitable?

If a minimum phase 44.1K resampler is used for the 96K version, the sample point at the -0.1dB level may be grossly out of peak, causing clipping in 16Bit int. It's not as lossless when it has to be limited after resampling.
1. The gold standard is linear phase.
2. It doesn't have to be limited, just apply negative gain so that the total peak is under 0 dB FS.

Another reason is that LossyFLAC 96KHz is also acceptable at around 570Kbps bitrate in some setting, and there is no significant bitrate increase over LossyFLAC 44.1KHz at around 480Kbps (-q 2.0 to 5.0).
18% additional bitrate bloat looks pretty significant.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Make_it_possible on 2023-08-08 09:39:42
Is it so high as to make 16/44.1 unsuitable?
Not really, 24Bit 96KHz down-conversion to 16Bit 44.1KHz with dither is still a useful mainstream approach.
For my personal workflow, I generally end up with 48KHz/44.1KHz for the final mastering output, even if the project is 96KHz.
I just think 96KHz lossy is an interesting experimental direction to go in.

1. The gold standard is linear phase.
2. It doesn't have to be limited, just apply negative gain so that the total peak is under 0 dB FS.
Yes, linear phase is the gold standard. But the actual use is more flexible. When downsampling, I choose minimum phase, linear phase or adjust their ratios to get a good match according the type of music.
For personal use, I certainly apply negative gain after downsampling. But for commercial needs, negative gain is sometimes unappealing and some workers want the peak sample point to be around 0dB.

18% additional bitrate bloat looks pretty significant.
According to LossyWAV 1.4.2's hybrid mode, I would say that 96KHz would require 15%-25% more bitrate than 44.1KHz to achieve a good approximation, which is coincidentally a bit close to the A-weighted SNR measurements.

But in a detailed LossyWAV 1.4.3b comparison, A-weighted SNR of LossyFLAC at 96KHz and 44.1KHz at the same bitrate behaved similarly in some of the newer noise shaping modes.

Arbitrarily, the sampling rate did not significantly affect the coding efficiency? I don't think conclusions likes it can be drawn easily.
I'm skeptical of pure SNR evaluations, and I'd like to hear what all the noise-shaping modes actually sound like at different bitrates before I jump to conclusions.

Meanwhile, LossyWAV 1.4.3b's new noise shaping mode has some auditory enhancement & SNR improvement in lossy compression at 300 to 500Kbps in 44.1K, and it even feels like it surpasses the wavpack lossy & Opus.
I'm interested in it.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Make_it_possible on 2023-08-10 17:01:37
My preliminary evaluation:

1. --shaping weighted is efficient, with slightly difference in listening to --shaping hybrid for the same or slightly lower parameters (e.g. -q 5 -s W 1 & -q 6 -s h).

2. The difference between shaping weighted 0/1/2/3 is small, but -s W 1/3 had fewer aliasing for the mouth-ess sound on a quiet background than -s W 0/2, which is slightly noticeable on lossy compressed Bluetooth channels and low performance DACs/amps.
I personal prefered -s W 1 for its lower bitrate, but sometimes -s W 3 sounds great by its lower noise level in noticeable frequency range.

3. Blue or violet noise shaping (-s f 0.5 / 1.0) works well in 88.2K/96K for high quality parameters (-q 6 to 10).
Violet noise shaping makes it sound like wavpack lossy 96K, but inappropriately increases the amount of audible high-frequency energy in low quality preset and increases the cost of bitrate.
And for 44.1K and 48K audio, violet noise shaping wasted too much bitrate and fall into bad listening when comparing other shape at the same low bitrate.
White noise (-s f 0) is another -s o (disable noise shaping) with minimum difference but cost more process time.

4. The high frequency noise level of fixed shaping (-s f) can be changed by the -f scale 0<n<=2, but the frequency is fixed?
I try to mark a 96K file as a 88.2K file to process (96K playback). The noticeable high frequency noise became slightly less at similar low playback bitrate.

5. I tested the same music files about LossyFLAC 96K -q 5 (totally 656Kbps) and LossyFLAC 48K -q 10 (totally 642Kbps).
Although the 96K error files were louder. In playback systems with normal high-frequency response, they come close.
But 44.1K/48K can still lower the bitrate, and bring less risk of system IMD in some Bluetooth in-ear headphones. It's true that resampled 44.1K LossyFLAC is the safer option. Low bitrate lossy 96K remains an experimental option.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Nick.C on 2023-08-12 11:07:50
4. The high frequency noise level of fixed shaping (-s f) can be changed by the -f scale 0<n<=2, but the frequency is fixed?
I try to mark a 96K file as a 88.2K file to process (96K playback). The noticeable high frequency noise became slightly less at similar low playback bitrate.
The shape of the gain curve used in fixed noise shaping is as below, with the scale parameter changing the amplitude (using a power relationship, i.e. scale 0.5 = root; scale 2.0 = square).
(https://cdn.discordapp.com/attachments/1139861898477719552/1139861925405138954/image.png)
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Make_it_possible on 2023-08-15 16:39:31
4. The high frequency noise level of fixed shaping (-s f) can be changed by the -f scale 0<n<=2, but the frequency is fixed?
I try to mark a 96K file as a 88.2K file to process (96K playback). The noticeable high frequency noise became slightly less at similar low playback bitrate.
The shape of the gain curve used in fixed noise shaping is as below, with the scale parameter changing the amplitude (using a power relationship, i.e. scale 0.5 = root; scale 2.0 = square).
(https://cdn.discordapp.com/attachments/1139861898477719552/1139861925405138954/image.png)

Oh, it seems to be fine.
The level creep from 4KHz to 10KHz doesn't actually sound bad, but above 10KHz it can sometimes sound a bit noticeable.

However, the high frequency noise spectrum of my test weighted and hybrid modes doesn't quite match that of the fixed mode, so isn't the fixed noise used in the fixed mode a subset of them?

Fixed Mode Scale 1.0:
(https://i.imgur.com/z6LewFn.png)

Weighted Mode 3:
(https://i.imgur.com/onWE2RL.png)

I also recently tested for sample peak interference.
I think keeping the audio file with sample peaks around -0.5dB provides enough room for LossyWAV to operate. It looks like keeping the peaks at -0dB is also not very suitable to utilize the full performance of LossyWAV, a mistake I made earlier.

Here is Alexey Lukin's article on Noise Shaping Dithering: Comparison of Word Length Reduction Systems for Digital Audio (http://audio.rightmark.org/lukin/dither/dither.htm)

Regarding fixed noise shaping, I think it's possible to make the high frequency noise a bit similar to ExtraBit.
ExtraBit is still interesting to listen to at 8Bit, and behaves somewhat transparently at loud volumes, with 44.1K getting FLAC 8Bit 380Kbps and 96K getting FLAC 8Bit 717Kbps.
Here's what it roughly looks like with noise shaping, with the 44.1/48K and 88.2/96K using inconsistent models.

For 44.1/48KHz:
(https://i.imgur.com/q1aqbho.png)
(https://i.imgur.com/h15FriA.png)

For 88.2/96KHz:
(https://i.imgur.com/lkYFq67.png)
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Nick.C on 2023-08-16 14:20:48
However, the high frequency noise spectrum of my test weighted and hybrid modes doesn't quite match that of the fixed mode, so isn't the fixed noise used in the fixed mode a subset of them?
Weighted and hybrid shaping are both adaptive shaping methods, i.e. they shape the noise to the shape of the signal, with a bit of added noise at the top end of the frequency range.

The "widening" of the spikes in the Weighted Mode 3 image is (at least in part) due to linear interpolation between FFT results for, if the default 3 analyses were used, the 32 sample & 64 sample FFT lengths when defining the shape of the adaptive noise shaping curve for that codec block for each channel.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Kraeved on 2024-02-14 19:16:21
Err…

Code: [Select]
$ lossyWAV.exe ...
lossyWAV beta 1.4.3b, Copyright (C) 2007-2023 Nick Currie. Copyleft.
lossyWAV beta version has reached expiry date (30th September 2023).
Please contact Nick.C for a new version.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Nick.C on 2024-02-16 12:54:52
Err…

Code: [Select]
$ lossyWAV.exe ...
lossyWAV beta 1.4.3b, Copyright (C) 2007-2023 Nick Currie. Copyleft.
lossyWAV beta version has reached expiry date (30th September 2023).
Please contact Nick.C for a new version.
Hi,

As there was no interaction in the six weeks between my last post and the expiry of the beta version, and has been none in the over four months since, it didn't seem that there was any interest in the changes in the beta version.

The last release version, version 1.4.2, is still there to download.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Kraeved on 2024-02-17 19:54:32
@Nick.C, what kind of feedback do you expect to receive to roll out version 1.4.3 final? Noise-shaping performance, right? I am, however, interested in the fixed bugs that you described as minor.

Well, to give this topic a boost, let me tell you about the last scenario where I tried to use LossyFLAC.

There is a music album consisting of ~20 gothic rock compositions. The preview generation feature of Foobar2000 helped me to create a demo (number of tracks × 15 seconds). Next, I planned to merge the cuts into a file with the embedded cuesheet or chapters. I tried various lossy encoders and settled on Qaac with -V109 setting, which is slightly above the default -V91. What did I achieve with your solution? lossywav -q H -s h -A | flac -5 produced a file twice as big (7.5 vs 15 MB). I still have the source material, and I'm ready to try again if you can advise me on more appropriate settings to reduce the size.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: shadowking on 2024-02-18 02:35:02
https://wiki.hydrogenaud.io/index.php?title=LossyWAV#Indicative_bitrate_reduction
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: Nick.C on 2024-02-18 16:49:18
@Nick.C, what kind of feedback do you expect to receive to roll out version 1.4.3 final? Noise-shaping performance, right? I am, however, interested in the fixed bugs that you described as minor.
Some feedback relating to how useful, or not, the additions were considered to be. Fair point about the minor bug fixes - I should put out a 1.4.2b with those at the very least.
There is a music album consisting of ~20 gothic rock compositions. The preview generation feature of Foobar2000 helped me to create a demo (number of tracks × 15 seconds). Next, I planned to merge the cuts into a file with the embedded cuesheet or chapters. I tried various lossy encoders and settled on Qaac with -V109 setting, which is slightly above the default -V91. What did I achieve with your solution? lossywav -q H -s h -A | flac -5 produced a file twice as big (7.5 vs 15 MB). I still have the source material, and I'm ready to try again if you can advise me on more appropriate settings to reduce the size.
Using "-q H" there's not really a way to reduce the size - a lower quality setting would need to be selected, as detailed in the link shadowking posted.
Title: Re: lossyWAV 1.4.2 Development (was 1.5.0)
Post by: punkrockdude on 2024-02-18 19:37:42
I am glad to see LossyWAV still being developed. I have used it a lot and still use it every now and then.