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.2 Development (was 1.5.0) (Read 165006 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #125 –
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.
a fan of AutoEq + Meier Crossfeed

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #126 –
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).

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #127 –
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.



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



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.

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #128 –
Quote from: Make_it_possible on
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.

Quote from: Make_it_possible on
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?

Quote from: Make_it_possible on
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.

Quote from: Make_it_possible on
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.
a fan of AutoEq + Meier Crossfeed

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #129 –
Quote from: magicgoose on
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.

Quote from: magicgoose on
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.

Quote from: magicgoose on
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.

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #130 –
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.

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #131 –
Quote from: Make_it_possible on
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).

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #132 –
Quote from: Nick.C on
Quote from: Make_it_possible on
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).


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:


Weighted Mode 3:


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

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:



For 88.2/96KHz:

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #133 –
Quote from: Make_it_possible on
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.
 

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #134 –
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.
• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #135 –
Quote from: Kraeved on
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.

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #136 –
@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.
• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #138 –
Quote from: Kraeved on
@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.
Quote from: Kraeved on
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.

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #139 –
I am glad to see LossyWAV still being developed. I have used it a lot and still use it every now and then.

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #140 –
Quote from: Nick.C on
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.
I am interested too. And the lower A & U quality options seem useful as WV can often beat X in terms of file size.

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #141 –
I'm currently in the middle of a bug hunt (to fix the issue behind something that guruboolez encountered when processing large 96kHz files) but do intend to release another beta in the near future.

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #142 –
I have some 24-bit/96Khz lossless music with bitrate of 4608kbps. When I compress with wavpack (-hh -x3) the bitrate goes down to ~3525kbps. When I process these audios with lossywav (-q H) and recompress with wavpack, the bitrate goes from 4608kbps to 700kbps.

It's a dramatic reduction in size, is that normal to have such a reduction? I suppose 1536kbps to be the transparent quality with wavpack lossy.

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #143 –
Quote from: przemyslawo on
I have some 24-bit/96Khz lossless music with bitrate of 4608kbps. When I compress with wavpack (-hh -x3) the bitrate goes down to ~3525kbps. When I process these audios with lossywav (-q H) and recompress with wavpack, the bitrate goes from 4608kbps to 700kbps.

It's a dramatic reduction in size, is that normal to have such a reduction? I suppose 1536kbps to be the transparent quality with wavpack lossy.
It's not unexpected to reduce the bitrate by such an amount. The test sample I'm using in debugging at the moment is 96kHz 24-bit and reduces to c.700kbps at -q H. If you are concerned at a lack of bitrate (of the FLAC compressed lossyWAV processed file), try "-q I" (insane, the highest quality preset).

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #144 –
Hybrid noise shaping (-s h) produces a WAV file that neither reference Vorbis nor John33's build can encode.

Source: history.wav

Code: [Select]
$ lossywav.exe history.wav -s h
lossyWAV 1.4.2, Copyright (C) 2007-2016 Nick Currie. Copyleft.
Sample Rate too low : 11.03kHz (Min=22.05kHz).
RIFF; 46464952-0000-0000-0000-000000000000; 00000000
fmt ; 20746D66-0000-0000-0000-000000000000; 00000010
fact; 74636166-ACF3-11D3-8CD1-00C04F8EDB8A; 00000000
data; 61746164-0000-0000-0000-000000000000; 0005A546
This is not supported.
RIFF; 46464952-0000-0000-0000-000000000000; 00000000
fmt ; 20746D66-0000-0000-0000-000000000000; 00000010
fact; 74636166-ACF3-11D3-8CD1-00C04F8EDB8A; 00000000
data; 61746164-0000-0000-0000-000000000000; 0005A546
Error reading '" ' ' chunk.

$ ffmpeg -i history.wav -af aresample=32000:resampler=soxr:precision=28 -bitexact history.ffmpeg.32khz.wav

$ lossywav.exe history.ffmpeg.32khz.wav -s h
Filename  : history.ffmpeg.32khz.wav
Settings  : --quality standard --shaping hybrid
File Info : 32.00kHz; 1 channel; 16 bit; 00:16.78, 1.024MiB
Results   : 0.0000 bits; 62.39x; 00:00.27; [F]
Feedback  : None.

$ oggenc.exe -q 1 history.ffmpeg.32khz.lossy.wav
Skipping chunk of type "fact", length 77
Skipping chunk of type "", length 274916961
Warning: Unexpected EOF in reading WAV header
ERROR: Input file "history.ffmpeg.32khz.lossy.wav" is not a supported format

$ oggenc2.exe -q 1 history.ffmpeg.32khz.lossy.wav
Skipping chunk of type "fact", length 77
Skipping chunk of type "", length 274916961
Warning: Unexpected EOF in reading WAV header
Warning: Unexpected EOF in reading WAV header
Warning: Unexpected EOF in reading WAV header
Warning: Unexpected EOF in reading WAV header
Warning: Unexpected EOF in reading WAV header
Warning: Unexpected EOF in reading WAV header
ERROR: Input file "history.ffmpeg.32khz.lossy.wav" is not a supported format

P.S. Also, within --longhelp, there are “-A disables old sperading mechanism…” and “--bitdist show distrubution…”.
• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #145 –
Does Vorbis handle the file without lossyWAV processing?

Does it work with lossyWAV output using any other processing settings?

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #146 –
Quote from: Nick.C on
Does Vorbis handle the file without lossyWAV processing?

Yes.

Code: [Select]
$ oggenc.exe -q 1 history.ffmpeg.32khz.wav
Opening with wav module: WAV file reader
Encoding "history.ffmpeg.32khz.wav" to "history.ffmpeg.32khz.ogg" at quality 1,00
Done encoding file "history.ffmpeg.32khz.ogg"
        File length:  0m 16,0s
        Elapsed time: 0m 01,0s
        Rate:         16,7796
        Average bitrate: 31,0 kb/s

Quote from: Nick.C on
Does it work with lossyWAV output using any other processing settings?

Yes.

Code: [Select]
$ lossywav.exe history.ffmpeg.32khz.wav
lossyWAV 1.4.2, Copyright (C) 2007-2016 Nick Currie. Copyleft.
Filename  : history.ffmpeg.32khz.wav
Settings  : --quality standard
File Info : 32.00kHz; 1 channel; 16 bit; 00:16.78, 1.024MiB
Results   : 0.0000 bits; 60.80x; 00:00.28; [F]
Feedback  : None.

$ oggenc.exe -q 1 history.ffmpeg.32khz.lossy.wav
Skipping chunk of type "fact", length 60
Opening with wav module: WAV file reader
Encoding "history.ffmpeg.32khz.lossy.wav" to "history.ffmpeg.32khz.lossy.ogg" at quality 1,00
Done encoding file "history.ffmpeg.32khz.lossy.ogg"
        File length:  0m 16,0s
        Elapsed time: 0m 01,0s
        Rate:         16,7796
        Average bitrate: 31,0 kb/s
• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #147 –
Please provide a link a copy of the 32kHz version of the file, the file in the previous link is 11.025kHz and therefore will not, as already discovered, be processed by lossyWAV.

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #148 –
Quote from: Nick.C on
Please provide a link a copy of the 32kHz version of the file, the file in the previous link is 11.025kHz and therefore will not, as already discovered, be processed by lossyWAV.

Code: [Select]
$ ffmpeg -i history.wav -af aresample=32000:resampler=soxr:precision=28 -bitexact history.ffmpeg.32khz.wav

• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data

Re: lossyWAV 1.4.2 Development (was 1.5.0)

Reply #149 –
Thanks. It seems that oggenc2 (the one I tested) does not take account of the FACT chunk being zero padded to an even length in bytes if the length of the chunk is odd (while leaving the stated chunk length as it was, even though the size of the FACT chunk in the file is one byte longer).

From memory (and strongly suggested by the time it has taken for this issue to be raised) the RIFF/WAVE specification calls for chunks to be padded to even length.

Removing the padding byte from the end of the FACT chunk gives the following:
Code: [Select]
F:\UserData\Media\Audio\Samples\Kraeved>oggenc2 -q 1 history.ffmpeg.32kHz.m1.lossy.wav
Skipping chunk of type "fact", length 65
Opening with wav module: WAV file reader
Encoding "history.ffmpeg.32kHz.m1.lossy.wav" to
         "history.ffmpeg.32kHz.m1.lossy.ogg"
at quality 1.00
        [ 94.4%] [ 0m00s remaining] -

Done encoding file "history.ffmpeg.32kHz.m1.lossy.ogg"

        File length:  0m 16.0s
        Elapsed time: 0m 01.0s
        Rate:         16.7796
        Average bitrate: 31.4 kb/s