Log in

View Full Version : LossyFlacGUI


Atak_Snajpera
16th December 2016, 22:40
http://i.cubeupload.com/bQyA1v.png

This application was designed to simplify process of processing FLAC files using lossywav.
Unfortunately Lossywav is quiet slow due to single threaded nature. In order to speed up processing with lossywav work is split in chunks using --skip and --until switches and then all chunks are executed simultaneously. Split points are done according to optimal block size (512 for 44.1/48KHz or 1024 for 96KHz or 2048 for 192 KHz).

Example for 2 threads.

chunk 1
"flac.exe" -d "audio.flac" --skip=0 --until=7379456 --silent --stdout | "lossywav.exe" - --stdinname "audio.001.wav" --force --outdir "..\LossyFlacGUI_temp"

chunk 2
"flac.exe" -d "audio.flac" --skip=7379456 --silent --stdout | "lossywav.exe" - --stdinname "audio.002.wav" --force --quality standard --outdir "..\LossyFlacGUI_temp"


No matter how many CPUs you have on motherboard each core will work at 100% reducing processing time significantly. This is very helpful if you work with long movie audio tracks. My Xeon E5-2690 (8C/16T) can convert 120 min 48KHz 6 channels 24 bit in ~1min:30s where before it took ~17min! Of course there is small bottleneck because wavs must be combined (using SOX) and encoded back to FLAC. I suppose this shouldn't be a big problem if you have decent MLC SSD and GPU (encoding with FlacCL).

Download
http://www.mediafire.com/file/qepld46cdvzhnil/LossyFlacGUI_v1.0.1.7z

mariush
17th December 2016, 01:19
I honestly don't see the point of making these not lossless , not lossy sound files.

If you want almost lossless, why don't you just go for Opus 512 kbps VBR (the maximum possible) ... you'll get almost transparent sound files, encoded much faster.

Atak_Snajpera
17th December 2016, 11:35
Because not all tvs support opus? Because this method is alot less agresive? Because 24 bit or even 16 bit audio is just an overkill for human beings? Lossywav by reducing bitdepth acts like video denoiser. Even gentle denoising can improve lossless video compression (ut video/magicyuv)

Gser
17th December 2016, 17:13
Because 24 bit or even 16 bit audio is just an overkill for human beings? Lossywav by reducing bitdepth acts like video denoiserLossy doesn't reduce bitdepth. That can be accomplished through a filter. I have tried LossyFLAC with Foobar before but didn't really see any need for it as a format. I tried for example compressing Matrix's TrueHD 5.1 audio with extreme compression setting in Lossy flac, the file went from 1,56 GB to 984 MB. I wanted to keep the 24 bit depth to maintain the low noise floor and high dynamic range. In comparison to the movie size the audio does not take up much space.

But in music use it is pretty much useless, I'd rather keep my files at the SACD quality in which I purchased them. Some I still have to purchase in CD quality which is unfortunate and most certainly don't need even more compression. But I am not unreasonable, if you listen to music through tin cans while using floppy disks as a storage format I can see the appeal of LossyFlac.

Atak_Snajpera
17th December 2016, 17:51
Lossy doesn't reduce bitdepth.

http://wiki.hydrogenaud.io/index.php?title=LossyWAV
lossyWAV is based on the lossyFLAC idea proposed by David Robinson at Hydrogenaudio, which is a method of carefully reducing the bitdepth of (blocks of) samples which will then allow the FLAC lossless encoder to make use of its wasted bits feature. The aim is to transparently reduce audio bit depth (by making some lower significant bits (lsb's) zero), consequently taking advantage of FLAC's detection of consistently-zeroed lower significant bits within each single frame and significantly increasing coding efficiency.[1] In this way the user can enjoy audio encoded using the same codec (which may be all important from a hardware compatibility perspective) at a reduced bitrate compared to the lossless version.

I tried for example compressing Matrix's TrueHD 5.1 audio with extreme compression setting in Lossy flac, the file went from 1,56 GB to 984 MB. I wanted to keep the 24 bit depth to maintain the low noise floor and high dynamic range.
I see much larger savings with standard preset. Examples

Original FLAC
General
Complete name : C:\Users\Dave\Desktop\audio1.flac
Format : FLAC
Format/Info : Free Lossless Audio Codec
File size : 211 MiB
Duration : 10 min 14 s
Overall bit rate mode : Variable
Overall bit rate : 2 885 kb/s

Audio
Format : FLAC
Format/Info : Free Lossless Audio Codec
Duration : 10 min 14 s
Bit rate mode : Variable
Bit rate : 2 885 kb/s
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 kHz
Bit depth : 24 bits
Stream size : 211 MiB (100%)
Writing library : libFLAC 1.3.1 (UTC 2014-11-25)

LossyFlac preset standard
Format : FLAC
Format/Info : Free Lossless Audio Codec
File size : 103 MiB
Duration : 10 min 14 s
Overall bit rate mode : Variable
Overall bit rate : 1 408 kb/s

Audio
Format : FLAC
Format/Info : Free Lossless Audio Codec
Duration : 10 min 14 s
Bit rate mode : Variable
Bit rate : 1 408 kb/s
Channel(s) : 6 channels
Channel positions : Front: L C R, Back: L R, LFE
Sampling rate : 48.0 kHz
Bit depth : 24 bits
Stream size : 103 MiB (100%)
Writing library : libFLAC 1.3.1 (UTC 2014-11-25)

LossyFlac preset extraportable
Format : FLAC
Format/Info : Free Lossless Audio Codec
File size : 74.2 MiB
Duration : 10 min 14 s
Overall bit rate mode : Variable
Overall bit rate : 1 012 kb/s

Audio
Format : FLAC
Format/Info : Free Lossless Audio Codec
Duration : 10 min 14 s
Bit rate mode : Variable
Bit rate : 1 012 kb/s
Channel(s) : 6 channels
Channel positions : Front: L C R, Back: L R, LFE
Sampling rate : 48.0 kHz
Bit depth : 24 bits
Stream size : 74.2 MiB (100%)
Writing library : libFLAC 1.3.1 (UTC 2014-11-25)

tebasuna51
17th December 2016, 20:00
Maybe OPUS is still not supported by some players, but also FLAC is not fully supported.

We have AAC than is compatible with any actual player.

There are some audio test than compare the quality between this method and the equivalent, or near, bitrate using AAC?

LoRd_MuldeR
17th December 2016, 22:39
Because 24 bit or even 16 bit audio is just an overkill for human beings? Lossywav by reducing bitdepth acts like video denoiser. Even gentle denoising can improve lossless video compression (ut video/magicyuv)

I don't think a bit-depth of 16-Bit is "overkill". It's more like 16-Bit is just about sufficient. At 8-Bit you get a whole lot of quantization noise (sounds like and old telephone). And if you ever tried amplifying a "quiet" section of a 16-Bit file, you will notice that quantization noise becomes very audible, event at 16-Bit. So, using 24-Bit or even 32-Bit (IEEE 754) can make a lot of sense - especially if you intend to process the audio. Proper dithering helps too, of course.

What really is "overkill" are sampling-rates above 48 KHz. That's because at a sampling-rate of 48 KHz you can already retain frequencies up to 24 KHz (without aliasing), according to Nyquist–Shannon sampling theorem. And the highest frequency humans can hear is about ~20 KHz. For most adults it's actually way lower. So, sampling frequencies higher than 48 KHz are pretty much "snakeoil". That's why modern audio formats, like Opus, are fixed at 48 KHz.

Gser
18th December 2016, 14:45
I see much larger savings with standard preset.

Ah yes, perhaps I should have mentioned I first had to convert the TrueHD file to a flac file which size was 2.5GB. So yes flac to flac compression is decent but seems TrueHD is better at compression than flac.

What I meant by bit depth is that indeed Lossy does fiddle around with perceived bit depth but even in the guide it says that it is optimized for 16-bit, 44.1kHz sources meaning it is better to lower the bit depth before compression rather than relay on its perceived bit depth manipulation for optimal compression.

Yoshi
4th January 2020, 19:10
While being a little late to kick in, the following is still valid so I don't wanna leave it uncommented after having stumbled across it:

I don't think a bit-depth of 16-Bit is "overkill". It's more like 16-Bit is just about sufficient.

It is more than sufficient, at least as an end-user format. Properly dithered, 16 Bit linear PCM exceeds any human's hearing capabilities both in SNR and dynamic range.

At 8-Bit you get a whole lot of quantization noise (sounds like and old telephone).

Partly true, however with decent noise shaping dither, that still sounds quiet decent and certainly above an old telephone's performance. Also for today's dynamic compressed charts crap, even less bits would suffice.

And if you ever tried amplifying a "quiet" section of a 16-Bit file, you will notice that quantization noise becomes very audible, event at 16-Bit.

True, but an invalid argument since one always can amplify any signal high enough so it will be above the hearing threshold. The point is that one won't perceive it as long as the playback gain level is adjusted in a way where a signal at maximum level won't damage your hearing.

So, using 24-Bit or even 32-Bit (IEEE 754) can make a lot of sense - especially if you intend to process the audio.

Replace the "especially" with "only", and the statement is correct.

Proper dithering helps too, of course.

Absolutely, the same is true for video by the way. Sadly, only very few seem to have a profound understanding here which gets us uncountable Blu-ray-releases with severe, ugly banding artifacts.

With the sampling part of your posting I entirely agree.

Cary Knoop
4th January 2020, 19:16
Flac is supposed to be lossless, why on Earth have all those compromising and potentially misleading solutions?

Atak_Snajpera
5th January 2020, 00:33
Flac is supposed to be lossless, why on Earth have all those compromising and potentially misleading solutions?

Why don't you post your question under correct address?
https://hydrogenaud.io/index.php/topic,55522.msg498343.html