Hydrogenaudio Forums

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 .
SimplePortal 1.0.0 RC1 © 2008-2018