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:- Code converted from Delphi to C++; Huge thanks to Tycho for kicking off the transcode;
- WAVE64 and RF64 compatibility introduced for large audio files;
- "--feedback" parameter introduced to allow noise introduced by bit-depth reduction to influence number of bits removed;
- Optional "altfilter" noise-shaping filter creation method added to adaptive noise shaping method;
- Optional curvilinear interpolation routine available in adaptive noise shaping method in addition to previous linear interpolation.
Download- Executable lossyWAV_v1.4.0.zip (http://www.hydrogenaud.io/forums/index.php?act=attach&type=post&id=8041)
- Source lossyWAV_CPP_Source_20141002_v1.4.0.zip (http://www.hydrogenaud.io/forums/index.php?act=attach&type=post&id=8042)
* on average, depending on content.
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:
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:
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:
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*:
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).
Looking good, thanks!
Typo:
lossyWAV 1.3.0 is released.
My error. I have requested that a moderator change it as I do not have access to it at the moment.
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.
@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).
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.
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!
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.
I also had problems with the command line but under Wine/Linux. First I had
C:\"Program Files"\lossywav\lossywav and C:\"Program Files"\flac\flac
but I had to move the files and instead use
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?
If you put the .exe files in ~/.wine/drive_c/windows/ then you don't have to specify the full path.
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.
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.
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.
I believe that halb27 used "eig" and "furious" samples for testing purposes.
My 55 sample test set comprises:
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
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.
Thank you Nick.C and Hex144. I will try to find some of these samples to try out which setting that suits me. Regards.
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.
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.
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.
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.
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.
herding_calls (http://dl.getdropbox.com/u/2681777/Problems/herding_calls.flac) for download.
herding_calls (http://dl.getdropbox.com/u/2681777/Problems/herding_calls.flac) for download.
Thank you!
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:
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....
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.
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"?
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.
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?
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.
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.
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?
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.
... 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.
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.
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?
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 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.
"Code converted from Delphi to C++"
If I may ask, does this we might see lossyWAV for other OSes?
"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)
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.
Rather than porting to another OS directly, just adding it to ffmpeg might be nice. Would make it accessible to everyone.
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)
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.
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?
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....
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 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 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.
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.
Could you please post your command line(s) for the processing / encoding? Thanks in advance.
Sure thing, Nick.
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.
I suspect that it can be a bug in WMAencode. I changed it a little, so try version 0.2.9c.
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.
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.
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
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.
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
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.
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....
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.
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 ?
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.
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.
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?
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.
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).
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.
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.
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.
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 think I have found cosmetic error. Instead of 00:60.84 it should show 01:00.84.
(http://i.cubeupload.com/CN2T0k.png)
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.
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.
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.
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 .
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.
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
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.
Anyone knows the command line in Linux? I use DeadBeeF so piping would be great! Regards.
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.
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.
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
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.
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!
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.
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!"
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).
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.
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.
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?
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.
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)]
Curious question:
Is there a way to store the encoding settings of lossywav as tag in FLAC?
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.
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?
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.
I think it is time to change:
-o%d
to
-o %d
in the usage description!
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?
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?
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.
Addendum:
For clarification: I meant a tag that is not present in the audio source file.
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.
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.
The way I do it.
/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
Thanks for all your help and support.
I think it is time to change:
-o%d
to
-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?