Hydrogenaudio Forums

Hydrogenaudio Forum => Validated News => Topic started by: Nick.C on 2014-10-02 15:43:09

Title: lossyWAV 1.4.0 Released
Post by: Nick.C on 2014-10-02 15:43:09
lossyWAV 1.4.0 is released.

lossyWAV is a near lossless audio processor which dynamically reduces the bitdepth of the signal on a block-by-block basis. Bitdepth reduction adds noise to the processed output. The added noise is adaptively shaped by default and can alternatively be fixed noise shaped or white noise depending on command line parameters. When lossyWAV processed output is compressed with certain lossless codecs (FLAC, Wavpack, Tak, LPAC, MPEG-4 ALS and WMA-Lossless) the bitrate of the output file is significantly* reduced compared to the lossless original.

Changes from 1.3.0b:Download* on average, depending on content.
Title: lossyWAV 1.4.0 Released
Post by: Nick.C on 2014-10-02 15:48:00
Code: [Select]
lossyWAV 1.4.0, Copyright (C) 2007-2014 Nick Currie. Copyleft.

This program is free software: you can redistribute it and/or modify it under
the terms of the GNU General Public License as published by the Free Software
Foundation, either version 3 of the License, or (at your option) any later
version.

This program is distributed in the hope that it will be useful,but WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.  See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with
this program.  If not, see <http://www.gnu.org/licenses/>.

Process Description:

lossyWAV is a near lossless audio processor which dynamically reduces the
bitdepth of the signal on a block-by-block basis. Bitdepth reduction adds noise
to the processed output. The amount of permissible added noise is based on
analysis of the signal levels in the default frequency range 20Hz to 16kHz.

If signals above the upper limiting frequency are at an even lower level, they
can be swamped by the added noise. This is usually inaudible, but the behaviour
can be changed by specifying a different --limit (in the range 10kHz to 20kHz).

For many audio signals there is little content at very high frequencies and
forcing lossyWAV to keep the added noise level lower than the content at these
frequencies can increase the bitrate dramatically for no perceptible benefit.

The noise added by the process is shaped using an adaptive method provided by
Sebastian Gesemann. This method, as implemented in lossyWAV, aims to use the
signal itself as the basis of the filter used for noise shaping. Adaptive noise
shaping is enabled by default.

Usage   : lossyWAV <input wav file> <options>

Example : lossyWAV musicfile.wav

Quality Options:

-q, --quality <t>    where t is one of the following (default = standard):
    I, insane        highest quality output, suitable for transcoding;
    E, extreme       higher quality output, suitable for transcoding;
    H, high          high quality output, suitable for transcoding;
    S, standard      default quality output, considered to be transparent;
    C, economic      intermediate quality output, likely to be transparent;
    P, portable      good quality output for DAP use, may not be transparent;
    X, extraportable lowest quality output, probably not transparent.

Standard Options:

-C, --correction     write correction file for processed WAV file; default=off.
-f, --force          forcibly over-write output file if it exists; default=off.
-h, --help           display help.
-L, --longhelp       display extended help.
-M, --merge          merge existing lossy.wav and lwcdf.wav files.
-o, --outdir <t>     destination directory for the output file(s).
-v, --version        display the lossyWAV version number.
-w, --writetolog     create (or add to) lossyWAV.log in the output directory.

Advanced Options:

-                    take WAV input from STDIN.
-c, --check          check if WAV file has already been processed; default=off.
                     errorlevel=16 if already processed, 0 if not.
-q, --quality <n>    quality preset (-5.0<=n<=10.0); (-5=lowest, 10=highest;
                     default=2.5; I=10.0; E=7.5; H=5.0; S=2.5; C=0.0; P=-2.5;
                     X=-5.0.
--, --stdout         write WAV output to STDOUT.
    --stdinname <t>  pseudo filename to use when input from STDIN.

Advanced Quality Options:

-a, --analyses <n>   set number of FFT analysis lengths, (2<=n<=7; default=3,
                     i.e. 32, 64 & 1024 samples. n = 2, remove 32 sample FFT;
                     n > 3 add 16; n > 4, add 128; n > 5, add 256, n > 6, add
                     512) n.b. FFT lengths stated are for 44.1/48kHz audio,
                     higher sample rates will automatically increase all FFT
                     lengths as required.
    --feedback [n]   enable experimental bit removal / adaptive noise shaping
                     noise limiter. Tuning has been carried out at -q X and
                     should have a negligible effect at -q S. Optional setting
                     (0.0 <= n <= 10.0, default = 0.0) automatically selects
                     the following parameters (0 = least effect, 10 = most):
       r, round <n>  limit deviation from expected added noise due to rounding
                     (-2.0 <= n <= 2.0, default = 0.0).
       n, noise <n>  limit added noise due to adaptive noise shaping
                     (-2.5 <= n <= 2.5, default = 0.0).
       a, aclips <n> number of permissible exceedences of adaptive noise
                     shaping level limit (0 <= n <= 64, default = 32).
       A, alevel <n> adaptive noise shaping level limit (-2.0 <= n <= 2.5,
                     default = 0.0).
       V, verbose    enable more detailed feedback information in output.
-I, --ignore-chunk-sizes.
                     ignore 'RIFF' and 'data' chunk sizes in input.
-l, --limit <n>      set upper frequency limit to be used in analyses to n Hz;
                     (12500 <= n <= 20000; default=16000).
    --linkchannels   revert to original single bits-to-remove value for all
                     channels rather than channel dependent bits-to-remove.
    --maxclips <n>   set max. number of acceptable clips per channel per block;
                     (0 <= n <= 16; default = 3,3,3,3,3,2,2,2,2,2,1,1,1,0,0,0).
-m, --midside        analyse 2 channel audio for mid/side content.
    --nodccorrect    disable DC correction of audio data prior to FFT analysis,
                     default=on; (DC offset calculated per FFT data set).
-n, --noskew         disable application of low frequency level reduction prior
                     to determination of bits-to-remove.
    --scale <n>      factor to scale audio by; (0.03125 < n <= 8.0; default=1).
-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)
       n, nowarp     disable warped noise shaping (use linear frequency shaping)
       o, off        disable noise shaping altogether (use simple rounding)
       s, scale <n>  change effectiveness of noise shaping (0 < n <= 2; default
                     = 1.0)
       t, taps <n>   select number of taps to use in FIR filter (32 <= n <= 256;
                     default = 64)
       w, warp       enable cubic interpolation when creating warped filter
-U, --underlap <n>   enable underlap mode to increase number of FFT analyses
                     performed at each FFT length, (n = 2, 4 or 8, default=2).

Output Options:

    --bitdist        show distrubution of bits to remove.
    --blockdist      show distribution of lowest / highest significant bit of
                     input codec-blocks and bit-removed codec-blocks.
-d, --detail         enable per block per channel bits-to-remove data display.
-F, --freqdist       enable frequency analysis display of input data.
-H, --histogram      show sample value histogram (input, lossy and correction).
    --longdist       show long frequency distribution data (input/lossy/lwcdf).
    --perchannel     show selected distribution data per channel.
-p, --postanalyse    enable frequency analysis display of output and
                     correction data in addition to input data.
    --sampledist     show distribution of lowest / highest significant bit of
                     input samples and bit-removed samples.
    --spread [full]  show detailed [more detailed] results from the spreading/
                     averaging algorithm.
-W, --width <n>      select width of output options (79<=n<=255).

System Options:

-B, --below          set process priority to below normal.
    --low            set process priority to low.
-N, --nowarnings     suppress lossyWAV warnings.
-Q, --quiet          significantly reduce screen output.
-S, --silent         no screen output.

Special thanks go to:

David Robinson       for the publication of his lossyFLAC method, guidance, and
                     the motivation to implement his method as lossyWAV.

Horst Albrecht       for ABX testing, valuable support in tuning the internal
                     presets, constructive criticism and all the feedback.

Sebastian Gesemann   for the adaptive noise shaping method and the amount of
                     help received in implementing it and also for the basis of
                     the fixed noise shaping method.

Tyge Lovset          for the C++ translation initiative.

Matteo Frigo and     for libfftw3-3.dll contained in the FFTW distribution
Steven G Johnson     (v3.2.1 or v3.2.2).

Mark G Beckett       for the Delphi unit that provides an interface to the
(Univ. of Edinburgh) relevant fftw routines in libfftw3-3.dll.

Don Cross            for the Complex-FFT algorithm originally used.
[/size]
Link to the hydrogenaudio wiki article (http://wiki.hydrogenaud.io/index.php?title=LossyWAV)

Suggested foobar2000 converter setup:

lossyFLAC:
Code: [Select]
Encoder: c:\windows\system32\cmd.exe
Extension: lossy.flac
Parameters: /d /c c:\"program files"\bin\lossywav - --quality standard --silent --stdout|c:\"program files"\bin\flac - -b 512 -5 -f -o%d --ignore-chunk-sizes
Format is: lossless or hybrid
Highest BPS mode supported: 24
lossyTAK:
Code: [Select]
Encoder: c:\windows\system32\cmd.exe
Extension: lossy.tak
Parameters: /d /c c:\"program files"\bin\lossywav - --quality standard --silent --stdout|c:\"program files"\bin\takc -e -p2m -fsl512 -ihs - %d
Format is: lossless or hybrid
Highest BPS mode supported: 24
lossyWV:
Code: [Select]
Encoder: c:\windows\system32\cmd.exe
Extension: lossy.wv
Parameters: /d /c c:\"program files"\bin\lossywav - --quality standard --silent --stdout|c:\"program files"\bin\wavpack -hm --blocksize=512 --merge-blocks -i - %d
Format is: lossless or hybrid
Highest BPS mode supported: 24
lossyWMALSL*:
Code: [Select]
Encoder: c:\windows\system32\cmd.exe
Extension: lossy.wma
Parameters: /d /c c:\"program files"\bin\lossywav - --quality standard --silent --stdout|c:\"program files"\bin\wmaencode.exe - %d --codec lsl --ignorelength
Format is: lossless or hybrid
Highest BPS mode supported: 24

Enclose the element of the path containing spaces within double quotation marks ("), e.g. C:\"Program Files"\directory_where_executable_is\executable_name. This is a Windows limitation.

*: Uses the wmaencoder executable written by lvqcl. Found here (http://www.hydrogenaud.io/forums/index.php?s=&showtopic=90519&view=findpost&p=767754).
Title: lossyWAV 1.4.0 Released
Post by: skamp on 2014-10-02 15:49:41
Looking good, thanks!
Title: lossyWAV 1.4.0 Released
Post by: skamp on 2014-10-02 15:51:06
Typo:

lossyWAV 1.3.0 is released.
Title: lossyWAV 1.4.0 Released
Post by: Nick.C on 2014-10-02 15:54:35
My error. I have requested that a moderator change it as I do not have access to it at the moment.
Title: lossyWAV 1.4.0 Released
Post by: 2Bdecided on 2014-10-03 12:38:23
Amazing stuff Nick, thank you. The shaping is getting very clever.

I think I've spotted what might be a bug. I think that when the size of the "fact" chunk is odd, you pad the chunk to be an even length, but you write the original odd length as the size of the chunk.

Beyond that, there's something in files created with a non-default command line which Cool Edit Pro (yes I still use that!) doesn't like, but I haven't figured out what yet.

Cheers,
David.
Title: lossyWAV 1.4.0 Released
Post by: [JAZ] on 2014-10-03 19:32:52
@2Bdecided: This is one of those things that it's not always followed (especially in windows), but blocks are expected to start in even positions. That was more strict in the older IFF format (The old motorola 68000 couldn't seek to odd positions, or something like that) and, i think, in AIFF.

Edit: Just to be clear... The chunk size was specified as the real size (so the extra byte would not be read as data), but the position to seek/skip was always expected to be even, and so there's the skip(1).
Title: lossyWAV 1.4.0 Released
Post by: 2Bdecided on 2014-10-03 23:27:30
Ah yes, you're right. I remembered the padding to align words, but had forgotten that it's not counted.

I'll try and figure out why CEP doesn't like it then. Not that it really matters, it's just strange.

Cheers,
David.
Title: lossyWAV 1.4.0 Released
Post by: themanintheshadows_2451 on 2014-10-07 22:09:23
The suggestions for fb2k setup need updating, because using those examples on an WinXP SP3 system gave me nothing but problems until I went (using TAK setup as an example) from this...

/d /c C:\"Program Files"\Encoders\LossyWAV\lossywav - --quality extreme --silent --stdout|C:\"Program Files"\Encoders\TAK\Applications\takc -e -p2m -fsl512 -ihs -v -md5 - %d


...to this.


/d /c C:\LossyWAV\lossywav - --quality extreme --silent --stdout|C:\LossyWAV\takc -e -p2m -fsl512 -ihs -v -md5 - %d


I also, with LossyWAV 1.4.0 installation, found that I had to put all the encoders I wanted into the folder itself for anything to work at all, unlike before.

Ah, upgrading! Love that process! 
Title: lossyWAV 1.4.0 Released
Post by: Nick.C on 2014-10-08 08:42:06
It should not have made any difference - although during development of 1.4.0 at least one user had issues getting the command line to work - from memory it was a Windows issue.

Glad that you found a remedy.

If the encoders are placed in a directory that is contained in the "PATH" variable, they should be picked up without any need to specify their path.
Title: lossyWAV 1.4.0 Released
Post by: punkrockdude on 2014-10-08 13:02:56
I also had problems with the command line but under Wine/Linux. First I had
Code: [Select]
C:\"Program Files"\lossywav\lossywav and C:\"Program Files"\flac\flac
but I had to move the files and instead use
Code: [Select]
C:\lossywav\lossywav and C:\lossywav\flac
to get it to work.

I tried altfilter last night and the bitrate went down a couple of kbps but I am interested in if this is noise shaping in alpha stage or do you consider it too maybe replace the default one in the future?
Title: lossyWAV 1.4.0 Released
Post by: skamp on 2014-10-08 13:09:58
If you put the .exe files in ~/.wine/drive_c/windows/ then you don't have to specify the full path.
Title: lossyWAV 1.4.0 Released
Post by: punkrockdude on 2014-10-08 13:26:59
If you put the .exe files in ~/.wine/drive_c/windows/ then you don't have to specify the full path.
Thank you for the suggestion, Skamp. I 'll keep it in mind next time I have any issues.
Title: lossyWAV 1.4.0 Released
Post by: Nick.C on 2014-10-08 13:39:56
I tried altfilter last night and the bitrate went down a couple of kbps but I am interested in if this is noise shaping in alpha stage or do you consider it too maybe replace the default one in the future?


It is optional as it has not received much (if any) independent listening - I have left it up to users to determine whether they want to use it. If it is well received then it may indeed end up as the default shaping filter creation method.
Title: lossyWAV 1.4.0 Released
Post by: punkrockdude on 2014-10-08 14:11:20
I am listening to a couple of samples I have encoded with altfilter and I have problems finding noise issues. I remember I could hear it using earlier versions about a year or two ago but now I hear no issues what so ever so far. Do you know of samples that extraportable usually has problem with? I also remember that classical pieces could end up having increased bitrate compared to lossless but now it does not seem to happen as far I have tested it. I am really impressed. I am strongly thinking about using LossyWAV instead of a lossy codec I use now.
Title: lossyWAV 1.4.0 Released
Post by: Nick.C on 2014-10-08 15:43:45
I believe that halb27 used "eig" and "furious" samples for testing purposes.

My 55 sample test set comprises:

Code: [Select]
01 - Ginnungagap - The Black Hole.flac
04 - Black Sabbath - Iron Man.flac
06_florida_seq.flac
10 - Dungeon - The Birth- The Trauma Begins.flac
14_Track03beginning.flac
16_Track03entreaty.flac
18_Track04cakewithtea.flac
34_Gabriela_Robin___Cats_on_Mars.flac
41_30sec.flac
A02_metamorphose.flac
A03_emese.flac
Angelic.flac
annoyingloudsong.flac
aps_Killer_sample.flac
Atem_lied.flac
ATrain.flac
Bachpsichord.flac
badvilbel.flac
bibilolo.flac
BigYellow.flac
birds.flac
bruhns.flac
cricket__insect___edit_.flac
dither_noise_test.flac
E50_PERIOD_ORCHESTRAL_E_trombone_strings.flac
eig.flac
Furious.flac
glass_short.flac
harp40_1.flac
herding_calls.flac
jump_long.flac
keys_1644ds.flac
ladidada_10s.flac
Liebe_so_gut_es_ging.flac
Moon_short.flac
Poets_of_the_fall___Shallow.flac
rach_original.flac
rawhide.flac
Rush___Hold_Your_Fire___Turn_the_Page.flac
S13_KEYBOARD_Harpsichord_C.flac
S30_OTHERS_Accordion_A.flac
S34_OTHERS_GlassHarmonica_A.flac
S35_OTHERS_Maracas_A.flac
S53_WIND_Saxophone_A.flac
SeriousTrouble.flac
swarm_of_wasps__edit_.flac
thewayitis.flac
the_product.flac
triangle.flac
triangle_2_1644ds.flac
trumpet.flac
udial.flac
utb.flac
VELVET.flac
wait.flac
Title: lossyWAV 1.4.0 Released
Post by: Hex144 on 2014-10-08 18:48:15
Do you know of samples that extraportable usually has problem with?

I think halb27 said he heard something with extraportable and herding_calls, iirc. Can't find his post.
Title: lossyWAV 1.4.0 Released
Post by: punkrockdude on 2014-10-09 03:52:16
Thank you Nick.C and Hex144. I will try to find some of these samples to try out which setting that suits me. Regards.
Title: lossyWAV 1.4.0 Released
Post by: halb27 on 2014-10-09 07:51:42
Do you know of samples that extraportable usually has problem with?

I think halb27 said he heard something with extraportable and herding_calls, iirc. Can't find his post.

I'm on holidays ATM, will look it up when I'll be back home.  But I also think it was herding_calls which gave audible deviations from the original for all quality levels below standard.
Title: lossyWAV 1.4.0 Released
Post by: Axon on 2014-10-12 17:44:40
FWIW, I've uploaded the sources to github: https://github.com/rtollert/lossywav (https://github.com/rtollert/lossywav)

Nick, feel free to set up an acct on github, and we can figure out how to transfer the repo over to you.

Somewhere in my copious free time I want to get this building on Linux.

EDIT: O, I see there's already a Sourceforge project with SVN, but it dates back to 2008. Hmm.
Title: lossyWAV 1.4.0 Released
Post by: Nick.C on 2014-10-13 02:42:31
Thanks, Axon.

The Sourceforge project was created quite some time ago as you correctly point out.

I have no preference (or experience, really) of online source management so am happy to have the latest code wherever it is easier to manage.

Nick.
Title: lossyWAV 1.4.0 Released
Post by: halb27 on 2014-10-18 11:46:02
Do you know of samples that extraportable usually has problem with?

I think halb27 said he heard something with extraportable and herding_calls, iirc. Can't find his post.

I'm on holidays ATM, will look it up when I'll be back home.  But I also think it was herding_calls which gave audible deviations from the original for all quality levels below standard.

I'm back home, and I've looked it up.
It was herding_calls which brought an audible deviation from the original for the extraportable and portable quality. With the economic quality it's still audible but it's not a real issue - quality is very close to being perfect.
Title: lossyWAV 1.4.0 Released
Post by: punkrockdude on 2014-10-18 18:55:35
Quote
I'm back home, and I've looked it up.
It was herding_calls which brought an audible deviation from the original for the extraportable and portable quality. With the economic quality it's still audible but it's not a real issue - quality is very close to being perfect.
I am also extremely impressed too with LossyWAV. I use ogg vorbis with a lot of extra parameters to satisfy my ears but LossyWAV results in lower bitrates  than my ogg encodings and I hear no difference between them. I tried to find that sample you talked about but couldn't find it. Do you maybe have it and are willing to upload it, please? Regards.
Title: lossyWAV 1.4.0 Released
Post by: halb27 on 2014-10-18 20:56:27
herding_calls (http://dl.getdropbox.com/u/2681777/Problems/herding_calls.flac) for download.
Title: lossyWAV 1.4.0 Released
Post by: punkrockdude on 2014-10-19 10:02:39
herding_calls (http://dl.getdropbox.com/u/2681777/Problems/herding_calls.flac) for download.
Thank you!
Title: lossyWAV 1.4.0 Released
Post by: sundance on 2014-11-13 10:39:35
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....
Title: lossyWAV 1.4.0 Released
Post by: Nick.C on 2014-11-13 11:08:06
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.
Title: lossyWAV 1.4.0 Released
Post by: sundance on 2014-11-13 11:50:40
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"?
Title: lossyWAV 1.4.0 Released
Post by: Nick.C on 2014-11-13 13:12:35
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.
Title: lossyWAV 1.4.0 Released
Post by: Fairy on 2014-11-24 10:22:37
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?
Title: lossyWAV 1.4.0 Released
Post by: shadowking on 2014-11-24 11:14:15
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.
Title: lossyWAV 1.4.0 Released
Post by: Fairy on 2014-11-24 11:18:41
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.
Title: lossyWAV 1.4.0 Released
Post by: themanintheshadows_2451 on 2014-11-24 20:01:01
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?
Title: lossyWAV 1.4.0 Released
Post by: DonP on 2014-11-24 20:12:44
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.
Title: lossyWAV 1.4.0 Released
Post by: halb27 on 2014-11-24 20:37:08
... Are there any samples available where Lossywav is failing at xtra portable mode? ...

Try herding_calls (http://dl.getdropbox.com/u/2681777/ProblemSamples/herding_calls.flac).
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.
Title: lossyWAV 1.4.0 Released
Post by: [JAZ] on 2014-11-24 21:05:54
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.
Title: lossyWAV 1.4.0 Released
Post by: Fairy on 2014-11-25 18:17:17
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?
Title: lossyWAV 1.4.0 Released
Post by: halb27 on 2014-11-25 20:48:22
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.
Title: lossyWAV 1.4.0 Released
Post by: Fairy on 2014-11-26 08:48:54
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.

Title: lossyWAV 1.4.0 Released
Post by: Agent69 on 2014-11-26 22:35:02
"Code converted from Delphi to C++"

If I may ask, does this we might see lossyWAV for other OSes?
Title: lossyWAV 1.4.0 Released
Post by: 2012 on 2014-12-14 15:10:58
"Code converted from Delphi to C++"

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


Yes.
Windows is assumed and its API is used in a few places. But that wasn't too hard to replace.

------

Is there any other source repository than this?
https://github.com/rtollert/lossywav (https://github.com/rtollert/lossywav)
Title: lossyWAV 1.4.0 Released
Post by: Nick.C on 2014-12-14 19:14:03
Is there any other source repository than this?
https://github.com/rtollert/lossywav (https://github.com/rtollert/lossywav)


That is the most recent upload of source - there is an old SourceForge project out there too.
Title: lossyWAV 1.4.0 Released
Post by: saratoga on 2014-12-14 19:24:37
Rather than porting to another OS directly, just adding it to ffmpeg might be nice. Would make it accessible to everyone.
Title: lossyWAV 1.4.0 Released
Post by: 2012 on 2014-12-14 19:35:32
I already managed to compile and run lossyWAV natively on GNU/Linux:
http://www.hydrogenaud.io/forums/index.php?showtopic=107774 (http://www.hydrogenaud.io/forums/index.php?showtopic=107774)
Title: lossyWAV 1.4.0 Released
Post by: GeSomeone on 2015-01-10 18:55:24
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.
Title: lossyWAV 1.4.0 Released
Post by: Fairy on 2015-01-10 20:40:26
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?
Title: lossyWAV 1.4.0 Released
Post by: Nick.C on 2015-01-10 20:46:44
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....
Title: lossyWAV 1.4.0 Released
Post by: Fairy on 2015-01-10 21:13:20
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 !
Title: lossyWAV 1.4.0 Released
Post by: CitizenInsomniac on 2015-01-15 10:35:42
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.
Title: lossyWAV 1.4.0 Released
Post by: Musique-Rabbit on 2015-01-15 13:20:45
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.
Title: lossyWAV 1.4.0 Released
Post by: Nick.C on 2015-01-15 17:56:01
I am not using any custom params with lossyWAV, just -q preset.


Could you please post your command line(s) for the processing / encoding?

Thanks in advance.
Title: lossyWAV 1.4.0 Released
Post by: CitizenInsomniac on 2015-01-15 21:06:34
Could you please post your command line(s) for the processing / encoding?  Thanks in advance.


Sure thing, Nick.

 
Code: [Select]
lossyWAV.exe source.wav -q E -f

WMAencode.exe source.lossy.wav output.wma --codec lsl


Using version 0.2.9b of WMAencode.

The reason I'm using file input/output and not pipe redirect is because I'm transcoding to multiple formats, so it's faster to preprocess once to file and encode multiple times.

 

Title: lossyWAV 1.4.0 Released
Post by: lvqcl on 2015-01-15 21:46:05
I suspect that it can be a bug in WMAencode. I changed it a little, so try version 0.2.9c.
Title: lossyWAV 1.4.0 Released
Post by: CitizenInsomniac on 2015-01-15 21:48:09
I suspect that it can be a bug in WMAencode. I changed it a little, so try version 0.2.9c.


Thanks, I will give that a try. Any idea what change between lossyWAV 1.3.0 and 1.4.0 may have triggered it?


Update:  Yep, 0.2.9c works with 1.4.0 output! Thanks!

I'm still curious about what change had triggered the issue in the first place. 

Title: lossyWAV 1.4.0 Released
Post by: shadowking on 2015-01-17 05:02:43
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 !


I reported it in the past. CD artist Ivri Lider, track: Dear sir.  Noise 'blip' in right channel very audible at low settings and still exists at -P. This was using lossywav 1.1 with noise shaping off. It still existed in v1.3 with A=OFF though I think with the recent NS it has improved or eliminated the problem. Going up to -C with recent versions or --Quality 3 with v1.1 also fixes it.

This is lossywav v1.3 -P setting: -  more subtle but still audiable

foo_abx 1.3.4 report
foobar2000 v1.0.3
2012/07/28 19:56:53

File A: C:\stuff\music\abx\09 - Dear Sir.flac
File B: C:\stuff\music\abx\Dear Sir2.flac

19:56:53 : Test started.
19:57:10 : 01/01  50.0%
19:57:21 : 02/02  25.0%
19:57:54 : 03/03  12.5%
19:58:05 : 04/04  6.3%
19:58:37 : 05/05  3.1%
19:58:50 : 06/06  1.6%
19:59:10 : 07/07  0.8%
19:59:32 : 08/08  0.4%
19:59:45 : Test finished.

----------
Total: 8/8 (0.4%)


Theres also the 'serioustrouble' mp3 problem track that sounded bad to me below -P and also 'Mandylion_short' sample . Again recent noise shaping changes in v1.3 ~ 1.4 may have improved these.
Title: lossyWAV 1.4.0 Released
Post by: Fairy on 2015-01-26 09:30:02
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 !


I reported it in the past. CD artist Ivri Lider, track: Dear sir.  Noise 'blip' in right channel very audible at low settings and still exists at -P. This was using lossywav 1.1 with noise shaping off. It still existed in v1.3 with A=OFF though I think with the recent NS it has improved or eliminated the problem. Going up to -C with recent versions or --Quality 3 with v1.1 also fixes it.

This is lossywav v1.3 -P setting: -  more subtle but still audiable

foo_abx 1.3.4 report
foobar2000 v1.0.3
2012/07/28 19:56:53

File A: C:\stuff\music\abx\09 - Dear Sir.flac
File B: C:\stuff\music\abx\Dear Sir2.flac

19:56:53 : Test started.
19:57:10 : 01/01  50.0%
19:57:21 : 02/02  25.0%
19:57:54 : 03/03  12.5%
19:58:05 : 04/04  6.3%
19:58:37 : 05/05  3.1%
19:58:50 : 06/06  1.6%
19:59:10 : 07/07  0.8%
19:59:32 : 08/08  0.4%
19:59:45 : Test finished.

----------
Total: 8/8 (0.4%)


Theres also the 'serioustrouble' mp3 problem track that sounded bad to me below -P and also 'Mandylion_short' sample . Again recent noise shaping changes in v1.3 ~ 1.4 may have improved these.


Thanks,

I'll try that one asap. I'm at work now so can't do it now.

At what moment (m:s) is the artifact(s) audible? I am not familiar with the album
Title: lossyWAV 1.4.0 Released
Post by: Nick.C on 2015-01-27 12:46:49
Theres also the 'serioustrouble' mp3 problem track that sounded bad to me below -P and also 'Mandylion_short' sample . Again recent noise shaping changes in v1.3 ~ 1.4 may have improved these.


If you have the inclination to re-visit these samples, I would suggest that the "--feedback <n>" parameter might be of some benefit when added to the processing command line.
Title: lossyWAV 1.4.0 Released
Post by: Fairy on 2015-01-30 13:10:51
Theres also the 'serioustrouble' mp3 problem track that sounded bad to me below -P and also 'Mandylion_short' sample . Again recent noise shaping changes in v1.3 ~ 1.4 may have improved these.


If you have the inclination to re-visit these samples, I would suggest that the "--feedback <n>" parameter might be of some benefit when added to the processing command line.


Totally offtopic, but your signature says:

:lossyWAV -q X -a 4 --feedback 4| FLAC -8 ~= 320kbps

Wouldn't it be better to suggest the right blocksize, because I think many people would just try -8 without further parameters:

:lossyWAV -q X -a 4 --feedback 4| FLAC -8 -b 512 ~= 320kbps

Title: lossyWAV 1.4.0 Released
Post by: Nick.C on 2015-01-30 13:22:09
Wouldn't it be better to suggest the right blocksize, because I think many people would just try -8 without further parameters:

:lossyWAV -q X -a 4 --feedback 4| FLAC -8 -b 512 ~= 320kbps



It might, I suppose - done. It will be sub-optimal higher or lower sample-rates than 44.1/48kHz though.
Title: lossyWAV 1.4.0 Released
Post by: Fairy on 2015-01-30 14:37:07
Wouldn't it be better to suggest the right blocksize, because I think many people would just try -8 without further parameters:

:lossyWAV -q X -a 4 --feedback 4| FLAC -8 -b 512 ~= 320kbps



It might, I suppose - done. It will be sub-optimal higher or lower sample-rates than 44.1/48kHz though.


You're right, but the most music is encoded at 44,1kHz and the resulting bitrate matches. When using 96kHz you cannot maintain the ~320kbit bitrate. I'm not sure if there are a lot of people who choose for 96kHz 24 bit samples would use LossyFLAC, these people often think you really need all those bits. It makes more sense to convert that to 16bit 44,1kHz (just my opinion) and THEN convert to LossyFLAC. I have a family member who says the sound of his high definition BD's is way better than CD. Also the video and colors are way better than the same BD ripped and played through XBMC for example  . Cannot convince the guy, don't attempt to again 

This weekend I will be testing the LossyFLAC X in my car (Peugeot 208 touchscreen plays FLAC and OGG). Ogg was my first choice, because a bitrate of ~128kbit is enough in a noisy car (for me), but every song the last few seconds (10?) are cut off. Not so nice. I will try FLAC to see if that performs better.

Again: My compliments for LossyWAV. Really like it. Do you have any new versions, functionality plans in the near future?

I'd really love to see some extreme options, like 160kbit LossyFLAC files. They don't have to be transparent. I'd like to see if that can be a good alternative for portable/car use....
Title: lossyWAV 1.4.0 Released
Post by: Nick.C on 2015-01-30 20:37:30
When using 96kHz you cannot maintain the ~320kbit bitrate. I'm not sure if there are a lot of people who choose for 96kHz 24 bit samples would use LossyFLAC, these people often think you really need all those bits.

I downloaded the free Peter Gabriel 24bit/96kHz tracks that were posted on 1st January - lossless FLAC was 3,000 kbit/s; lossyFLAC --standard -a 4 --feedback 4 resulted in 647 kbit/s with an average of between 12 and 14 bits removed for the tracks.

.... which got me thinking - what would the resultant bitrate have been at the "Insane" quality preset.... Answer: 901 kbit/s with an average of between 10.6 and 12 bits removed.
Title: lossyWAV 1.4.0 Released
Post by: GeSomeone on 2015-02-01 17:45:03
I'm not sure if there are a lot of people who choose for 96kHz 24 bit samples would use LossyFLAC

I downloaded the free Peter Gabriel 24bit/96kHz tracks that were posted [..]
.... which got me thinking - what would the resultant bitrate have been at the "Insane" quality preset.... Answer: 901 kbit/s with an average of between 10.6 and 12 bits removed.

Exactly, and the bits should be removed only where you can't hear them. I read on this forum the opinion that the least significant bits (5 or 6) of 24bit audio contain probably "random noise". That is because the noise floor of equipment and studios.
The savings on this type of files are huge, when using lossyWav, sometimes multiple GB per album (especially when they are in 5.1).

I totally agree that downsampling to 16/48kHz is also a valid option.

BTW did you remember to use FLAC -b 1024 ?
Title: lossyWAV 1.4.0 Released
Post by: Nick.C on 2015-02-01 20:47:43
The savings on this type of files are huge, when using lossyWav, sometimes multiple GB per album (especially when they are in 5.1).

I totally agree that downsampling to 16/48kHz is also a valid option.

BTW did you remember to use FLAC -b 1024 ?


The savings are as follows:

FLAC: 620MB; 3,000 kbit/s;
Insane: 187MB, 30.2%; 901 kbit/s; Saving: 433MB, 69.8%;
Standard: 130MB, 21.0%; 625 kbit/s; Saving: 490MB, 79.0%.

I had remembered to set the FLAC block size to 1024 for Insane but reprocessed the Standard set and saw a 22 kbps, 5MB, 0.8% reduction in size.
Title: lossyWAV 1.4.0 Released
Post by: Fairy on 2015-02-03 12:37:11
I'm not sure if there are a lot of people who choose for 96kHz 24 bit samples would use LossyFLAC
I downloaded the free Peter Gabriel 24bit/96kHz tracks that were posted [..]
.... which got me thinking - what would the resultant bitrate have been at the "Insane" quality preset.... Answer: 901 kbit/s with an average of between 10.6 and 12 bits removed.
Exactly, and the bits should be removed only where you can't hear them. I read on this forum the opinion that the least significant bits (5 or 6) of 24bit audio contain probably "random noise". That is because the noise floor of equipment and studios.
The savings on this type of files are huge, when using lossyWav, sometimes multiple GB per album (especially when they are in 5.1).

I totally agree that downsampling to 16/48kHz is also a valid option.

BTW did you remember to use FLAC -b 1024 ?

As he is the author of LossyWAV I guess he is using the right command line options am I wrong

PS. in response to Nick.C. The gain in saved space is indeed quite a lot, but the people who stick to these bitdepths/samplingsfrequencies are hard to convince.

I downloaded some HD tracks also, but immediatly downsampled them to 44/16 (SoX) via Foobar. I absolutely cannot hear ANY difference. I even didn't bother using 48kHz as it is dividable by 2.
Title: lossyWAV 1.4.0 Released
Post by: zerowalker on 2015-04-10 11:39:01
I wonder, what is best in terms of re-encoding afterwards.

Wave -> lossyWav -> "some lossy format"
or
Wave -> Opus(x bitrate) -> "some lossy format"

I know of course Flac is the best (or any lossless), but you probably get my question.

Also is there any special commands i need to care about, saw one saying something about 1024 block?
Title: lossyWAV 1.4.0 Released
Post by: GeSomeone on 2015-04-14 16:39:42
Also is there any special commands i need to care about, saw one saying something about 1024 block?

1024 blocks are only used when the sample rate is 88.2k or 96k. So in a (more) normal case you should specify a block size of 512 to the lossless codec you will use to compress a lossy.wav file. (example: flac -b 512 ).
Look for command line or script examples from Nick.C. There must be a wiki page somewhere.

About going from one lossy to another, you should see what suits you best. It all depends on what you use it for and what's acceptable to you.
Title: lossyWAV 1.4.0 Released
Post by: zerowalker on 2015-04-14 20:07:27
Also is there any special commands i need to care about, saw one saying something about 1024 block?

1024 blocks are only used when the sample rate is 88.2k or 96k. So in a (more) normal case you should specify a block size of 512 to the lossless codec you will use to compress a lossy.wav file. (example: flac -b 512 ).
Look for command line or script examples from Nick.C. There must be a wiki page somewhere.

About going from one lossy to another, you should see what suits you best. It all depends on what you use it for and what's acceptable to you.


Ah i see, thanks.

Well the lossy -> lossy is a hard one for me.
I i can easily spare bitrate, but lossless is a bit much.
Therefore i wondered if Opus would be able to make more transparent at higher bitrate compared to lossyWAV (i can afford around 320-512 bitrate).
Title: lossyWAV 1.4.0 Released
Post by: Nick.C on 2015-04-14 20:56:07
Look for command line or script examples from Nick.C. There must be a wiki page somewhere.

About going from one lossy to another, you should see what suits you best. It all depends on what you use it for and what's acceptable to you.

There is: here (http://wiki.hydrogenaud.io/index.php?title=LossyWAV) (although it is a bit out of date with respect to some of the newer options).

Ah i see, thanks.

Well the lossy -> lossy is a hard one for me.
I i can easily spare bitrate, but lossless is a bit much.
Therefore i wondered if Opus would be able to make more transparent at higher bitrate compared to lossyWAV (i can afford around 320-512 bitrate).

Standard quality yields c.440 kbit/s for my music collection. Regarding lossy to lossy - it's your call.
Title: lossyWAV 1.4.0 Released
Post by: Atak_Snajpera on 2015-04-15 17:44:12
Are you going to add mutithreading processing in order to speed up whole process? I have 8C/16T CPU and processing of movie track 5.1 takes to much time due single threaded code.
Title: lossyWAV 1.4.0 Released
Post by: Fairy on 2015-04-20 13:22:51
Are you going to add mutithreading processing in order to speed up whole process? I have 8C/16T CPU and processing of movie track 5.1 takes to much time due single threaded code.


I suggest using Foobar2000 and process from there. It is capable to start more conversions simultaneously.

With the task manager you can set the amount of processors assigned to foobar. Setting too much CPU's can result in HDD seeking (overload) slowing things down. Just try with 4 first and build up from there keeping an eye on the system resources.
Title: lossyWAV 1.4.0 Released
Post by: Atak_Snajpera on 2015-04-22 16:28:28
Are you going to add mutithreading processing in order to speed up whole process? I have 8C/16T CPU and processing of movie track 5.1 takes to much time due single threaded code.


I suggest using Foobar2000 and process from there. It is capable to start more conversions simultaneously.

With the task manager you can set the amount of processors assigned to foobar. Setting too much CPU's can result in HDD seeking (overload) slowing things down. Just try with 4 first and build up from there keeping an eye on the system resources.


Your method is: Build 8 houses in the same time
But I prefer: Build 1 house 8 times faster

I was thinking about encoding multiple chunks of data (let's say 1min) in the same time and then combine all chunks into one FLAC file.
I think I can achieve that with something like this

ffmpeg.exe 00:00:00 00:00:00.999 -> lossywav -> flac encoder -> 01.flac
ffmpeg.exe 00:00:01 00:00:01.999 -> lossywav -> flac encoder -> 02.flac
ffmpeg.exe 00:00:02 00:00:02.999 -> lossywav -> flac encoder -> 03.flac

Unfortunately there is major problem. How to combine multiple flacs into one flac without RE-ENCODING?! Btw. Forget about copy /b method...
Title: lossyWAV 1.4.0 Released
Post by: Atak_Snajpera on 2015-04-25 16:44:29
I think I have found cosmetic error. Instead of 00:60.84 it should show 01:00.84.
(http://i.cubeupload.com/CN2T0k.png)
Title: lossyWAV 1.4.0 Released
Post by: Nick.C on 2015-04-25 17:56:32
I think I have found cosmetic error. Instead of 00:60.84 it should show 01:00.84.


Thanks Atak - I will investigate. Apologies on the lack of multi-threaded processing - it's a fairly major rewrite that I'm not ready to commit to.
Title: lossyWAV 1.4.0 Released
Post by: Atak_Snajpera on 2015-04-26 11:16:51
Last question. Processing all channels at the same will be difficult to implement? I mainly work with 6 , 8 channel tracks so 6 , 8 times faster encoding would be still great on my xeon 8c/16t.
Title: lossyWAV 1.4.0 Released
Post by: Fairy on 2015-04-29 10:40:23
Are you going to add mutithreading processing in order to speed up whole process? I have 8C/16T CPU and processing of movie track 5.1 takes to much time due single threaded code.


I suggest using Foobar2000 and process from there. It is capable to start more conversions simultaneously.

With the task manager you can set the amount of processors assigned to foobar. Setting too much CPU's can result in HDD seeking (overload) slowing things down. Just try with 4 first and build up from there keeping an eye on the system resources.


Your method is: Build 8 houses in the same time
But I prefer: Build 1 house 8 times faster

I was thinking about encoding multiple chunks of data (let's say 1min) in the same time and then combine all chunks into one FLAC file.
I think I can achieve that with something like this

ffmpeg.exe 00:00:00 00:00:00.999 -> lossywav -> flac encoder -> 01.flac
ffmpeg.exe 00:00:01 00:00:01.999 -> lossywav -> flac encoder -> 02.flac
ffmpeg.exe 00:00:02 00:00:02.999 -> lossywav -> flac encoder -> 03.flac

Unfortunately there is major problem. How to combine multiple flacs into one flac without RE-ENCODING?! Btw. Forget about copy /b method...


I get the point, but multi-cpu processing one file is a major change in code, just like the developer says. Many file compression programs have problems with multicore cpu's. You can use multi cpu's, but many times at the cost of compression ratio, because the data becomes uncomparable when it is sliced in separate chunks. For FLAC's this is less of a problem, but general data compression relies on big dictionaries...

I see no problem in the 8 houses method. Normally you have so much FLAC files that there is no gain in speed by processing 1 file by 8 cpu's.
Title: lossyWAV 1.4.0 Released
Post by: GeSomeone on 2015-04-29 14:12:55
I see no problem in the 8 houses method. Normally you have so much FLAC files that there is no gain in speed by processing 1 file by 8 cpu's.

This might be true if you compress an album in separate tracks, but as the original poster said "movie track 5.1 takes to much time".  The only mitigation is that when processing in a "pipe", at least lossywav and flac are separate processes  .
Title: lossyWAV 1.4.0 Released
Post by: Nick.C on 2015-04-30 10:49:02
Last question. Processing all channels at the same will be difficult to implement? I mainly work with 6 , 8 channel tracks so 6 , 8 times faster encoding would be still great on my xeon 8c/16t.


To process using more than a single thread would require a great deal of recoding to allow parallel processing rather than sequential processing.

Looking around, FFMPEG can be used to take a multi-channel audio file and split it into multiple mono files (I've tried it on a 6-channel file and it didn't take too long at all). If these files were processed using multiple instances of lossyWAV and then re-muxed into a single multi-channel audio file (I did this too - it worked well) then compressed with FLAC, I would expect that the overall processing time would be significantly reduced.
Title: lossyWAV 1.4.0 Released
Post by: akin0780 on 2015-04-30 17:32:36
Last question. Processing all channels at the same will be difficult to implement? I mainly work with 6 , 8 channel tracks so 6 , 8 times faster encoding would be still great on my xeon 8c/16t.


To process using more than a single thread would require a great deal of recoding to allow parallel processing rather than sequential processing.

Looking around, FFMPEG can be used to take a multi-channel audio file and split it into multiple mono files (I've tried it on a 6-channel file and it didn't take too long at all). If these files were processed using multiple instances of lossyWAV and then re-muxed into a single multi-channel audio file (I did this too - it worked well) then compressed with FLAC, I would expect that the overall processing time would be significantly reduced.


Nick,

A totally different trajectory here: do the following parameters (-a n and/or --feedback n) provide any additional benefits at high bitrates (Q5-7.5)?

Thanks in advance.

Alex
Title: lossyWAV 1.4.0 Released
Post by: themanintheshadows_2451 on 2015-04-30 22:51:04
The suggestions for fb2k setup need updating, because using those examples on an WinXP SP3 system gave me nothing but problems until I went (using TAK setup as an example) from this...

/d /c C:\"Program Files"\Encoders\LossyWAV\lossywav - --quality extreme --silent --stdout|C:\"Program Files"\Encoders\TAK\Applications\takc -e -p2m -fsl512 -ihs -v -md5 - %d


...to this.


/d /c C:\LossyWAV\lossywav - --quality extreme --silent --stdout|C:\LossyWAV\takc -e -p2m -fsl512 -ihs -v -md5 - %d


I also, with LossyWAV 1.4.0 installation, found that I had to put all the encoders I wanted into the folder itself for anything to work at all, unlike before.

Ah, upgrading! Love that process! 


I ended up having to go through this stuff again with my new Windows 8.1 laptop. So I think, at this point, it's not a Windows problem, it's a LossyWAV problem.
Title: lossyWAV 1.4.0 Released
Post by: punkrockdude on 2015-04-30 22:55:42
Anyone knows the command line in Linux? I use DeadBeeF so piping would be great! Regards.
Title: lossyWAV 1.4.0 Released
Post by: themanintheshadows_2451 on 2015-04-30 23:04:29
I've noticed, also, a weird problem when creating a single LossyWAV file in fb2k. Before, I'd end up with a file that looked like this:


01. Until The Night.lossy.wv

Instead, I now get this:

01. Until The Night.lossy.wv.lossy.wv



Interestingly, I don't have this problem at all, whatsoever, in fb2k when I select an entire album to be encoded into LossyWAV files.

BTW: I've double-checked my settings. They're set up according to the instructions in the 1st post of this thread, so that's not the problem.


Title: lossyWAV 1.4.0 Released
Post by: 2012 on 2015-05-01 07:20:27
Last question. Processing all channels at the same will be difficult to implement? I mainly work with 6 , 8 channel tracks so 6 , 8 times faster encoding would be still great on my xeon 8c/16t.


To process using more than a single thread would require a great deal of recoding to allow parallel processing rather than sequential processing.

Looking around, FFMPEG can be used to take a multi-channel audio file and split it into multiple mono files (I've tried it on a 6-channel file and it didn't take too long at all). If these files were processed using multiple instances of lossyWAV and then re-muxed into a single multi-channel audio file (I did this too - it worked well) then compressed with FLAC, I would expect that the overall processing time would be significantly reduced.


FWIW, I tried a lower level approach, that is using multi-threading support in libfftw3. That did not improve performance. In fact, lossywav ended up running slower. IIUC, libfftw3 was spending more time synchronizing than processing because the plans were too small.
Title: lossyWAV 1.4.0 Released
Post by: saratoga on 2015-05-01 15:58:02
FWIW, I tried a lower level approach, that is using multi-threading support in libfftw3.


I can tell you without even trying that this is going to fail.  Parallelizing an individual FFT does not make sense until you are orders of magnitude larger than anything used in audio.  Usually you only bother with large, higher dimensional FFTs.  Parallelizing a 512 point FFT would mean that each processor was doing nanoseconds worth of work before you had to synchronize
Title: lossyWAV 1.4.0 Released
Post by: alter4 on 2016-01-02 20:30:06
Something wrong with --check option. I used 64bit lossywav with the following command line. I got strange message in my windows console and then lossywav simply crashed.

Code: [Select]
     D:\temp\777>lossywav 6.wav --quality high  -c
     lossyWAV 1.4.0, Copyright (C) 2007-2014 Nick Currie. Copyleft.
     This is free software under the GNU GPLv3+ license; There is NO WARRANTY, to
     the extent permitted by law. <http://www.gnu.org/licenses/> for details.
     lossyWAV FACT Chunk not found. File not marked as processed.
     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; 030E2860
     ☺
     ; 000A0001-0000-0000-0000-000000000000; 000A0005
    
     Too much WAV information before 'data' chunk!
Title: lossyWAV 1.4.0 Released
Post by: Nick.C on 2016-01-02 21:05:01
The check function does not process the file - it simply checks the file to determine whether it has already been processed - and was included to facilitate batch processing of files.

The key line is: "lossyWAV FACT Chunk not found. File not marked as processed." The program exits with "ERRORLEVEL=16" if the file is processed (i.e. the FACT chunk is found) and "ERRORLEVEL=0" if not.

Title: lossyWAV 1.4.0 Released
Post by: alter4 on 2016-01-02 21:15:19
I tried
lossywav 6.wav  -c
before. The issue here why lossywav crashes after printing these lines. I tried different wav files, result the same - crash after printing line "Too much WAV information before 'data' chunk!"
Title: lossyWAV 1.4.0 Released
Post by: Nick.C on 2016-01-02 23:25:41
Thanks for that - I'll have a look at it (it's been a while since I used "check" on anything as the FACT chunk is lost when data is piped in to FLAC).
Title: lossyWAV 1.4.0 Released
Post by: alter4 on 2016-01-03 12:52:45
Thanks guys!
One more question. Is it safe to use lossyWAV on 24bit-44k source and 16bit -48k source? What flac block size should be specified in each case? Sorry if it already has been clarified somewhere.
Title: lossyWAV 1.4.0 Released
Post by: Nick.C on 2016-01-03 13:44:25
lossyWAV will process audio with sample-rates from 32 kHz to 384 kHz on sample bit-depths from 8 bit to 24 bit. The definition of "safe" in this context is unclear.

The processing block size for 44.1/48 kHz sample rates is 512 samples.
Title: lossyWAV 1.4.0 Released
Post by: alter4 on 2016-01-03 21:34:34
When I say safe I mean safe for my ears  , in general I mean optimization for transparency for those bit depth/sample rate params. When I use 16bit 44k I am sure profile extreme is transparent, Can I be sure for 16bit 48k with same profile?
Title: lossyWAV 1.4.0 Released
Post by: Nick.C on 2016-01-03 22:44:16
Can I be sure for 16bit 48k with same profile?


.... only by doing the same form of personal testing that you did to arrive at the conclusion that it was adequate for 16 bit / 44.1 kHz.
Title: lossyWAV 1.4.0 Released
Post by: Nick.C on 2016-01-06 13:22:59
The issue here why lossywav crashes after printing these lines. I tried different wav files, result the same - crash after printing line "Too much WAV information before 'data' chunk!"


Bug fixed in beta 1.4.1h [here (https://www.hydrogenaud.io/forums/index.php?showtopic=109239)]
Title: lossyWAV 1.4.0 Released
Post by: naturfreak on 2016-01-06 18:12:49
Curious question:
Is there a way to store the encoding settings of lossywav as tag in FLAC?
Title: lossyWAV 1.4.0 Released
Post by: Nick.C on 2016-01-06 19:25:47
If the audio file is processed to a WAV file then compressed using FLAC with --keep-foreign-metadata then the FACT chunk will be retained (this contains the lossyWAV settings).

If, however, the audio file is processed and piped to FLAC then the FACT chunk would be lost (as FLAC does not support piped additional chunks) so is not output.

The best way would be to add a user defined tag using a tagging tool. I would use the foobar2000 file properties dialog as I use that program to convert all of my lossless to lossyFLAC.
Title: lossyWAV 1.4.0 Released
Post by: naturfreak on 2016-01-06 22:50:24
Thank you for your help, Nick.

I had a more automatized solution for this in my mind. Adding tags to each file manually can be a lot of work after converting a lot of audio files.

Can tagging of lossyway settings in FLAC output file be done by script or something else?
Title: lossyWAV 1.4.0 Released
Post by: Nick.C on 2016-01-07 09:40:44
There's no need to edit the tags individually.

In foobar2000 there does not seem to be a limit to the number of files that can be selected simultaneously when amending the properties - the whole processing/conversion batch could be selected and the tag added as easily as a single file.
Title: lossyWAV 1.4.0 Released
Post by: punkrockdude on 2016-01-07 15:14:35
I think it is time to change:
Code: [Select]
-o%d
to
Code: [Select]
-o %d
in the usage description! 
Title: lossyWAV 1.4.0 Released
Post by: naturfreak on 2016-01-07 15:25:40
There's no need to edit the tags individually.

In foobar2000 there does not seem to be a limit to the number of files that can be selected simultaneously when amending the properties - the whole processing/conversion batch could be selected and the tag added as easily as a single file.


Thanks, Nick.

What about making that task easier by copying the lossywav setting info as text into a system variable or into clipboard?
Title: lossyWAV 1.4.0 Released
Post by: lvqcl on 2016-01-07 15:36:07
I had a more automatized solution for this in my mind. Adding tags to each file manually can be a lot of work after converting a lot of audio files.

Can tagging of lossyway settings in FLAC output file be done by script or something else?

How do you convert your files?
Title: lossyWAV 1.4.0 Released
Post by: naturfreak on 2016-01-07 16:42:04

I use foobar2000 most of the time for that task.

Maybe a feature request for converter in f2k? Add a user defined tag to the converted files.
Title: lossyWAV 1.4.0 Released
Post by: naturfreak on 2016-01-07 18:37:01
Addendum:
For clarification: I meant a tag that is not present in the audio source file.
Title: lossyWAV 1.4.0 Released
Post by: Nick.C on 2016-01-07 19:39:52
Maybe a feature request for converter in f2k? Add a user defined tag to the converted files.


.... or simply click on one track in the converter output dislog box, CTRL-A, right-click, properties, first tab, double click in a free cell at the bottom left, enter "lossyWAV settings" in the "Field name:" field, select Single Value, enter the settings themselves in the "Single Value" field. Not as clean as adding a tag automatically - but possible now.
Title: lossyWAV 1.4.0 Released
Post by: sundance on 2016-01-08 09:29:11
As suggested earlier by Case, I do it like that:
In foobar's converter settings, edit the FLAC output format setting you use with LossyWAV where you change encoder to "Custom".
Then add this string to parameters line: -T "LossyWav-Setting=Processed with lossyWAV (standard)" (or the switches you used).
This will add a custom tag "LossyWav-Setting" to your LossyFLAC files after encoding.
Title: lossyWAV 1.4.0 Released
Post by: alter4 on 2016-01-08 13:19:26
The way I do it.
Code: [Select]
/D /C d:\tools\foobar2000\lossywav\lossyWAV  - --quality high --silent --stdout|d:\tools\foobar2000\flac - -b 512 --tag "lossywav profile=high" -8 -s -o%d --ignore-chunk-sizes
Title: lossyWAV 1.4.0 Released
Post by: naturfreak on 2016-01-08 20:07:33
Thanks for all your help and support.
Title: Re: lossyWAV 1.4.0 Released
Post by: punkrockdude on 2016-01-31 16:06:34
I think it is time to change:
Code: [Select]
-o%d
to
Code: [Select]
-o %d
in the usage description! 
This, that I wrote earlier, has been a problem under Wine and Linux. Does this change make any problem on real Windows?
SimplePortal 1.0.0 RC1 © 2008-2018