Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: lossyWAV 1.4.0 Released (Read 78563 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

lossyWAV 1.4.0 Released

Reply #25
I've learned that lossyWAV works by adding shaped noise to the audio file.
Does this mean that, if the source file already reaches 0 dBFS, the processed file could possibly be clipped?
Is this behaviour controlled by "--maxclips <n>"?
And how to read this result (esp. 'Extant clips') of lossyWAV:
Code: [Select]
Results   : 10.6378 bits; 3.96x; 01:17.07; [I]
Feedback  : Extant clips: 759;

Btw. an amplitude analysis of the processed file show a peak amplitude of -0.44 dB, so no clips (a least no 0 dBFS clips...)

.sundance.

edit: Sorry, this should have better been a new thread - maybe a mod could correct my mistake....

lossyWAV 1.4.0 Released

Reply #26
If the file has samples exceeding the maximum value associated with the number of bits to remove, i.e. above the maximum sample value of 32767-(2^(bits-to-remove)-1) then the sample will be considered to be an extant clip (even when, as you point out, the maximum sample amplitude for your file is c.±32620 (if a 16-bit file)).

Samples that, when shaped and rounded, then exceed the maximum sample value are considered to be "new" clips and it is these that the "maxclips" parameter will affect.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.4.0 Released

Reply #27
Nick,
If the file has samples exceeding the maximum value associated with the number of bits to remove, i.e. above the maximum sample value of 32767-(2^(bits-to-remove)-1) then the sample will be considered to be an extant clip...
I think I have to chew over that for a while before I fully understand it...

Regarding --maxclips <n> defaults:
Do the 16 values shown on the help page (default = 3,3,3,3,3,2,2,2,2,2,1,1,1,0,0,0) correspond to the quality values (-5 .. 10), meaning "insane" (10) defaults to "maxclips=0"while "high" (5.0) defaults to "maxclips=1"?

lossyWAV 1.4.0 Released

Reply #28
The maxclips automatic settings are as you surmised. To remove the possibility of lossyWAV adding clips to the audio, I would use "--maxclips 0", the same as for the insane quality setting.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.4.0 Released

Reply #29
Hello!

I am really impressed by the results of lossywav in combination with FLAC. I am considering to use it. I have quite enough diskspace available, but the gain is really substantial, which makes it more 'portable', even portable enough to use it directly on my portable player. I have samples going from 1100kbit/s going down to 350kbit/s and I cannot hear any difference at all.

Today I ordered new headphones (AKG) to replace my Sennheiser HD-580 and will try again to see if there is any quality degradation noticable.

I even tried a bit less scientific method by loading the original (inverted) and the lossyflac version in Audiacity to 'see' what has been left out (YES I am aware this is not a technically correct way to do the testing) but I was just curious how the 'difference' samples sounded compared to vorbis etc...

Now comes my real question. Is it possible to run the conversion twice, 3 times?
Example: Today I chose to use Lossywav+flac at Insane mode and convert all my music to that format. Some time later I choose to go for Standard mode because it is inaudible to me and maybe later even Xtra portable mode. Lossywav has a build in check to see if it is already processed, but after removing the flag or converting to flac you can choose to eliminate this flag, you could do the trick again and again.

Does every step involve extra degradation or is this a process that can repeated numerous times?

At this moment I just cannot choose the 'right' mode yet. I think Standard is the way to go, but I really hear no difference in Xtra portable mode (my listening enviroment was not really quiet!!) but simply cannot believe yet it is really transparent... What is the best way to do? I am not in direct need of extra diskspace, but my collection is quite substantial so I could wait off course, but that keeps me waiting forever. Version 1.4 looks stable enough to begin using it. Smaller files are just easier to use, especially if it is a factor 3 smaller.

The LossyWAV algorithm introduces 'noise', but when switching to a 'lower' quality level, does that really matter or will the rounding process introduce errors at some point?

I am really interrested what the experts at this technique think about that?

lossyWAV 1.4.0 Released

Reply #30
IMO you should stick to quality yielding 400..550k  (min economic profile.. max extreme)  . Generally 4:1 compression works great but i recommend 3:1 when considering rare problematic samples or transcoding to other lossy formats.

lossyWAV 1.4.0 Released

Reply #31
IMO you should stick to quality yielding 400..550k  (min economic profile.. max extreme)  . Generally 4:1 compression works great but i recommend 3:1 when considering rare problematic samples or transcoding to other lossy formats.


It's more like, when encoding to insane mode and after that to standard mode, if the quality exactly the same as encoding directly to standard mode or do I lose quality along the path?

PS. Are there any samples available where Lossywav is failing at xtra portable mode? When I can get my hands on some really hard to process samples, I can do some more testing.

The music I'm currently playing is quite easy to encode, except piano music, these are even bigger, sometimes, this is expected behaviour, however I don't really get it how this technically works. Piano music produce some extra noise and al lot of harminics, but the difference between a piano and a guitar and corresponding bitrate are something to dive in and do some research after. I'm just interested in the underlying technology.

lossyWAV 1.4.0 Released

Reply #32
IMO you should stick to quality yielding 400..550k  (min economic profile.. max extreme)  . Generally 4:1 compression works great but i recommend 3:1 when considering rare problematic samples or transcoding to other lossy formats.


So you can actually transcode LossyWAV files to lossy versions? (AAC, MP3) I've always heard the total opposite was the case. Is this a new feature of LossyWAV v1.4.0? Or has this always been an option?
ghostman

lossyWAV 1.4.0 Released

Reply #33
The music I'm currently playing is quite easy to encode, except piano music, these are even bigger, sometimes, this is expected behaviour, however I don't really get it how this technically works.


One of the reasons is that solo piano compresses pretty well in FLAC to begin with.

I believe the reason it gets bigger is that lossyflac for some reason (couldn't tell you that)  uses a smaller block size than default flac.

lossyWAV 1.4.0 Released

Reply #34
... Are there any samples available where Lossywav is failing at xtra portable mode? ...

Try herding_calls.
To me it's not totally fine (though not hard to accept) with the economic quality.
From lossyWAV I expect an extremely good quality even with hard samples because otherwise I'd prefer a more effecient encoding scheme like aac.
As for that the economic quality is the lowest quality level I'd personally consider using, just as shadowking suggested.
If I'd consider using lossyWAV again (and I really like lossyWAV), I guess I'd use standard.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.4.0 Released

Reply #35
ok, let's answer several of the questions:


About multiple encode<->decode passes: The original lossywav algorithm would have accepted several passes of encoding without doing damage, if it used the same parameters.
Right now, there might be a difference, and that difference might increase each time due to the additional noise shaping that is done in order to improve on quality while maintaining compression. (i.e the noise is not aplied in a broad way, but localized where there is a signal loud enough to make it less likely to be heard).

About transcoding to other codecs: Transcoding, generally, is not recommended because encoders don't make a distinction between artifacts and audio, and this means that usually each transcode is further away from the original, even if using the same bitrate all the time.
Said that, there are types and types of transcoding:  For example MP3 x kbps -> MP3 xkbps is worse than, for example musepack xkbps -> musepack xkbps.
But in case of lossywav, since the way it works is much different than how lossy encoders work, the difference from using lossless or lossywav as source is minimal. Concretely, i mean that the noise (which is lossywav's artifact) is not incremented by a lossy pass.



So, with that in mind, yes, you have two options:


Use lossyflac with a relatively high setting like shadowking suggested. Then, if you want to go portable, and it supports flac, you can generate a lower rate lossywav to see if it fits you (Since it is supposed to increase the noise level, the added noise in the first pass should not matter)  , or use a lossy codec supported without much worrying that it is not a lossless original.

lossyWAV 1.4.0 Released

Reply #36
Thanks for the answers!

I've tried the herding_calls sample... Even with my new AKG headphones I am struggling to really distinguish the samples.
When I am finding the difference, after that listening to the original I get the feeling the artifact is there already, although not as pronounced as in the processed version.

I hear some sort of noise (more like a scraping sound) in the first tone that is made.

Sorry, hard to explain, since English is not my native language...

At this moment I will keep an eye on this program and experiment with it (a lot  ) but I think I will wait before processing my entire collection at this moment. Having the absolute original files is fine, but on the other hand, will anybody even be able to find a sample in my collection that does not sound like it should do at the standard setting?

lossyWAV 1.4.0 Released

Reply #37
I was thinking like you when I was using lossyWAV.
But if you don't mind the disk space (nowadays hardly a problem for archiving the music) I'd keep the original compressed with a lossless format like FLAC.
Brings you ease of mind when converting the lossy way. As for this as you can't hear an issue with herding_calls (the problem is with the long-stretched tone, and I can hear it best with volume pretty restricted) or other samples: you don't need to worry using economic or below. In case you should ever run into trouble you can still re-encode.
lame3995o -Q1.7 --lowpass 17

lossyWAV 1.4.0 Released

Reply #38
I was thinking like you when I was using lossyWAV.
But if you don't mind the disk space (nowadays hardly a problem for archiving the music) I'd keep the original compressed with a lossless format like FLAC.
Brings you ease of mind when converting the lossy way. As for this as you can't hear an issue with herding_calls (the problem is with the long-stretched tone, and I can hear it best with volume pretty restricted) or other samples: you don't need to worry using economic or below. In case you should ever run into trouble you can still re-encode.



I think you're right. Guess I will be using lossyWAV for my portable device, although OGG is quite sufficient there because when sporting and running I don't need transparent quality

I have 2 NAS systems (primary and backup) with 12TB storage each, so I have some time left before really running out of space.


lossyWAV 1.4.0 Released

Reply #39
"Code converted from Delphi to C++"

If I may ask, does this we might see lossyWAV for other OSes?


lossyWAV 1.4.0 Released

Reply #41
Is there any other source repository than this?
https://github.com/rtollert/lossywav


That is the most recent upload of source - there is an old SourceForge project out there too.
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

lossyWAV 1.4.0 Released

Reply #42
Rather than porting to another OS directly, just adding it to ffmpeg might be nice. Would make it accessible to everyone.


lossyWAV 1.4.0 Released

Reply #44
I recently did a few tests with lossyWav 1.4.0 in combination with FLAC 1.3.1.
I noticed that with files of 96kHz (or 88kHz) sample rate, the compression was consistently better with 1024 sample blocks than with the lossyWav default, 512 sample blocks. Of course the block length of both lossyWav and FLAC should be 1024 in that case.

Does that make sense? Double sample rate, double the number of samples per block?

BTW those 96kHz files happened to have a bitdepth of 24.
In theory, there is no difference between theory and practice. In practice there is.

lossyWAV 1.4.0 Released

Reply #45
I recently did a few tests with lossyWav 1.4.0 in combination with FLAC 1.3.1.
I noticed that with files of 96kHz (or 88kHz) sample rate, the compression was consistently better with 1024 sample blocks than with the lossyWav default, 512 sample blocks. Of course the block length of both lossyWav and FLAC should be 1024 in that case.

Does that make sense? Double sample rate, double the number of samples per block?

BTW those 96kHz files happened to have a bitdepth of 24.


Just a wild guess. When using 1024 sample blocks you math this up like 512 sample blocks on 48KHz (close to 44.1). 512 sample blocks have been tested as the optimum size, so you have succesfully 'aligned' the samplerate/blocksize ratio.

When using 96KHz with 512 sample blocksize is like 44.1 (or 48 because it's close) with a 256 sample blocksize...

Am I right?

lossyWAV 1.4.0 Released

Reply #46
When using 96KHz with 512 sample blocksize is like 44.1 (or 48 because it's close) with a 256 sample blocksize...

Am I right?


Indeed you are - 44.1/48 kHz use 512 samples per codec-block; 88.2/96 kHz use 1024; 176.4/192 kHz use 2048 and 352.8/384 kHz would use 4096.

I should really add this to the wiki....
lossyWAV -q X -a 4 -s h -A --feedback 2 --limit 15848 --scale 0.5 | FLAC -5 -e -p -b 512 -P=4096 -S- (having set foobar to output 24-bit PCM; scaling by 0.5 gives the ANS headroom to work)

 

lossyWAV 1.4.0 Released

Reply #47
When using 96KHz with 512 sample blocksize is like 44.1 (or 48 because it's close) with a 256 sample blocksize...

Am I right?


Indeed you are - 44.1/48 kHz use 512 samples per codec-block; 88.2/96 kHz use 1024; 176.4/192 kHz use 2048 and 352.8/384 kHz would use 4096.

I should really add this to the wiki....


Hello Nick.C,

I'm still looking for that killer sample. I've tried "herding Calls" a thousand times but it doesn't convince me, I cannot ABX the artifacts that are created by LossyWAV (did not really ABX because even without I cannot hear the difference). This offcourse is a good thing! Still I am looking for a sample that has some hearable difference agains the original in X mode. Is there a sample out there? My ears are quite allright for my age of 32, shouldn't be the problem I hope. Sometimes I think I hear it, but then I think it just my knowledge if cheating me because I know which sample I'm playing.

PS. Is there a way to tell LossyWAV to do some extreme things? Like taking out way more bits than in the X mode? I would like to see how far I can go before it gets really nasty.

Unfortunately I do not have the programming skills to create this myself.

Thanks you in advance for your answer !

lossyWAV 1.4.0 Released

Reply #48
I think I may have found a bug in v1.4.0. When I use version v1.3.0 and feed the resulting lossy wav to WMAEncode, it works fine. When I feed the output of lossyWAV 1.4.0 to WMAEncode, I get the error "Unexpected EOF in reading WAV header" from WMAEncode.

I tried using the --ignorelength parameter with WMAEncode, it didn't make a difference. The only variable that makes a difference is the lossyWAV version number.

I am not using any custom params with lossyWAV, just -q preset.

lossyWAV 1.4.0 Released

Reply #49
I think I may have found a bug in v1.4.0. When I use version v1.3.0 and feed the resulting lossy wav to WMAEncode, it works fine. When I feed the output of lossyWAV 1.4.0 to WMAEncode, I get the error "Unexpected EOF in reading WAV header" from WMAEncode.

I tried using the --ignorelength parameter with WMAEncode, it didn't make a difference. The only variable that makes a difference is the lossyWAV version number.

I am not using any custom params with lossyWAV, just -q preset.


I use foobar2000 to do the same and no issue is found.