lossyWAV 1.2.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 white noise to the processed output.
Changes from 1.1.0c:- Now compatible with FFTW (requires libfftw3-3.dll to exist on the path);
- Spreading function changed;
- Noise shaping now off by default - can be switched on to automatic or user specified value;
- Introduction of --altpreset parameter which modifies internal presets and lowers upper frequency limit used in determining noise floor to 15.16kHz;
- Major code cleanup.
Download [maintenance release 1.2.0b]:- Executable [attachment=6238:lossyWAV_1.2.0b.zip]
- Source [attachment=6239:lossyWAV...2_1.2.0b.zip]
lossyWAV 1.2.0, Copyright © 2007,2008,2009 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 white
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.
Usage : lossyWAV <input wav file> <options>
Example : lossyWAV musicfile.wav
Quality Options:
-I, --insane highest quality output, suitable for transcoding;
-E, --extreme high quality output, also suitable for transcoding;
-S, --standard default quality output, considered to be transparent;
-P, --portable good quality output for DAP use, not fully transparent.
-Z, --zero lowest quality preset, probably contains artifacts.
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:
- if filename="-" then WAV input is taken from STDIN.
-t, --altpreset enable alternative preset model which changes default
behaviour regarding limit and shaping (if selected).
-a, --analyses set number of FFT analysis lengths, (3<=n<=5), default=2.
--blockdist show distribution of lowest / highest significant bit of
input codec-blocks and bit-removed codec-blocks.
-c, --check check if WAV file has already been processed; default=off.
errorlevel=16 if already processed, 0 if not.
-i, --impulse force use of additional shorter FFT analysis; default=off,
automatic for -q 3 and above.
-l, --limit <n> set upper frequency limit to be used in analyses to n Hz;
(10000<=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 codec
block. (0<=n<=16) Default = (3,3,3,3,2,1,0,0,0,0,0).
-m, --midside analyse 2 channel audio for mid/side content.
-q, --quality <n> quality preset (0.000<=n<=10.000); (10=highest, 0=lowest;
default = --standard = 5; --insane = 10; --extreme = 7.5;
--portable = 2.5; --zero = 0)
--sampledist show distribution of lowest / highest significant bit of
input samples and bit-removed samples.
--scale <n> scaling factor from WaveGain, etc; (0.0<n<=8.0),default=1.
-s, --shaping [n] enable fixed noise shaping, automatic if no value input.
(0.00<=n<=1.00); automatic = q/10; 0.00 = off, 1.00 = 100%
effectiveness, 0.50 = 50%, etc.
--stdout write processed WAV output to STDOUT.
--stdinname <t> pseudo filename to use when input from STDIN.
-U, --underlap <n> enable underlap mode to increase number of FFT analyses
performed at each FFT length, (2<=n<=8); default=2.
-X, --sortspread enable sort based spreading; default=off.
System Options:
-B, --below set process priority to below normal.
-d, --detail enable detailed bits-to-remove information output mode
--low set process priority to low.
-n, --nowarnings suppress lossyWAV warnings.
-Q, --quiet significantly reduce screen output.
--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 noise shaping coefficients and help in using them
in the lossyWAV noise shaping implementation.
Matteo Frigo and for the excellent libfftw3-3.dll contained in the FFTW
Steven G Johnson distribution (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.hydrogenaudio.org/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 - --standard --silent --stdout|c:\"program files"\bin\flac - -b 512 -5 -f -o%d
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 - --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 - --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
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.
Thank you very much for the new release, Nick.
Thank you guys.
BTW: i encoded a fiona apple cd and -P -t was slightly larger than old -P. Is this normal ? I thought -t was more aggressive to save a few bits. In any case i am happy with old -P.
Great work! Thank you.
BTW: i encoded a fiona apple cd and -P -t was slightly larger than old -P. Is this normal ? I thought -t was more aggressive to save a few bits. In any case i am happy with old -P.
The same here with my primary test corpus of 46 (probably problem) files.
The quality scale for --altpreset basically extends the range of the default -q 0 to 5 over the range -q -4 to 5. As --portable equates to -q 2.5 in both, -q 2.5 --altpreset (sort of) equates to -q 2.9999 in the default range (there is a bit of a jump at -q 3 as the impulse detection mechanism kicks in....).
Great work! Thank you.
BTW: i encoded a fiona apple cd and -P -t was slightly larger than old -P. Is this normal ? I thought -t was more aggressive to save a few bits. In any case i am happy with old -P.
The same here with my primary test corpus of 46 (probably problem) files.
For problem samples it is very welcome if bitrate goes up in a noticeable way.
For 'normal' samples bitrate of -P should be pretty close to each other when comparing plain vanilla -P against -P --altpreset.
-P --altpreset is more demanding in keeping noise level low in the range up to 15.2 kHz, but doesn't care about noise in the 15.2 ... 16 kHz range which plain vanilla -P does.
From my point of view as a user, lossyWAV is one of the most innovative audio compression techniques in recent years. The fact that it can (and should) be used with existing lossless codecs is genius. Thank you.
one of the most innovative audio compression techniques in recent years
That's going straight onto my CV!
Can me and Nick call you for references?
(joking!)
Cheers,
David.
"Honour to whom honour is due"
(I am proud to be able to find answers in my favourite dictionary...)
Joke apart: I regard LossyWav as something really elegant.
As a title paraphrase of the well known song of Budgie, lossyWAV is the biggest thing since powdered milk
For me "--zero --altpreset" sounds much better (than without altpreset switch), and I don't hear high noise and distortion.
Maybe it would be useful to enable --altpreset by default for high compression modes??
--zero --altpreset equates to approximately -q 1.63 --limit 15159 in the default scale. This is due to the scale stretch mentioned above.
I have some trouble with mp3 transcoding. Last month i compared original V5 mp3 vs lossywav -P V5 mp3 . I abxed 5/5 several times on nearly every sample i tried. The problem wasn't always noticeable but sound very peculiar - like an artifact. Today i tried again with v1.2 -q 2.5, 3.0 and 1.5. I found a passage again and abxed 5/5, the narrowed it down and got 8/8
At -q 4 i didn't abx it. Not sure what is happening or what quality level is needed. With wv lossy 300k range its generaly much harder. I remember Bryant mentioning lossywav noise goes in steps of 6db - could that be problem for transcoding ?
At -q 4 i didn't abx it. Not sure what is happening or what quality level is needed.
maybe you have established that lossyWav -q 4 is needed for your transcodings. Keep in mind that lossyWav was never specifically tuned for transcoding. It is just hoped that it has an advantage to other lossy->lossy transcoding. All depends on how the last encoder handles the added noise...
With lossyWav, due to the tuning that has been done, every release you must again find your "sweetspot" -q value. And now there is also the alternative setting with --altpreset, that has a subtle different range.
I'm not complaining, it's progress .
Thank you, shadowking, for ABXing.
Not very good news, but valuable experience of lossyWAV behavior.
Do you mind publishing the sample and tell us the bad spot of the sample, shadowking?
I'd like to learn about transcoding quality whether it depends on -V.
Can you ABX the mp3 encoding of say -P --altpreset when you choose a better mp3 quality like -V2?
Thank you, shadowking, for ABXing.
Not very good news, but valuable experience of lossyWAV behavior.
Do you mind publishing the sample and tell us the bad spot of the sample, shadowking?
I'd like to learn about transcoding quality whether it depends on -V.
Can you ABX the mp3 encoding of say -P --altpreset when you choose a better mp3 quality like -V2?
Better news: I did more testing yesterday and as per your suggestion, I found out that the main problem was V5 itself - the samples i tested were already ruined by mp3 artifacts. LW didn't add any artifact that wasn't already there though the amplitude of it can change slightly. This is normal.
I tested V4 this time with plain Q1.5, 2.5, 3.5 without NS and things were way better. Q2.5 and over were fine. Q1.5 was abxable in one segment (lame V4 in itself wasn't fully transparent) but q1.5 added a bit of intensity to it. On subsequent trials in was somewhat harder to abx that part. Overall 1.5 was also very good - i test it as a 'low anchor'. Also tested Nero AAC q0.5 with lw Q2.5 and everything seemed transparent.
I'll do more tests soon and report them here.
From the Wiki:
Question: Why create a processor which means that I cannot be sure that a lossless file is truly lossless?
Answer: Unless one creates the lossless file personally, one can never be completely sure that the file is indeed lossless. e.g. If a WAV file is encoded to MP3 and then transcoded to a lossless codec, how can this pre-processing be easily determined?
What kind of circular gibberish is this? That's not an answer. It's false logic, and a poor attempt at justifying the existence of this particular software.
How about an honest answer to that question?
What kind of answer do you expect to this question? First, I don't think the answer needs to "justify" lossywav's existence. Second, nobody can ever be exactly sure what processing has taken place before the input, whether a given processor's output is WAV (lossy), WAV (lossless), mp3, or other.
If anything, the premise of the question is faulty; not the answer.
What kind of circular gibberish is this? That's not an answer. It's false logic, and a poor attempt at justifying the existence of this particular software.
How about an honest answer to that question?
Which bit of the answer was not "honest" (in your interpretation)?
An early criticism of lossyFLAC / lossyWAV was that lossy output was by design to be contained in a lossless container. "How do we tell the difference?" came the cry.... "Make it yourself." was the response.
There are ways of determining whether audio has been processed by lossyWAV (if you know where and how to look) - I am content that those who use lossyWAV will know which of their files are lossless and which are lossy.
An early criticism of lossyFLAC / lossyWAV was that lossy output was by design to be contained in a lossless container. "How do we tell the difference?" came the cry.... "Make it yourself." was the response.
Nick, I'm w/ Singaiya on this one. The point presumes that there may be something "wrong" with processsing/encoding/compression - which is a false pretense - and then doesn't give a thorough explanation to the counter. Personally, I don't think it belongs in the wiki, and I don't think you should even have to answer that question. If someone is that worried about their sources, then they need to go rob mixing studios of the masters.
Better news: ... Q2.5 and over were fine. ...
Thank you, shadowking. Though the --portable quality level does not necessarily have the property that transcoding to mp3 is fine it would have been a little bit disappointing.
Better news: ... Q2.5 and over were fine. ...
Thank you, shadowking. Though the --portable quality level does not necessarily have the property that transcoding to mp3 is fine it would have been a little bit disappointing.
I think Nick's performed a minor miracle!
(Pre-processing with my original implementation changed the already audible artefacts on some samples when encoded to mp3 from
much higher "lossyWAV" bitrates than you're seeing now.)
Cheers,
David.
This kind of command parameters use, can be frustrating and rejecting:
You can create a batch file, say lossyFLAC.bat, in your FLAC folder with this contents:
c:\programme\flac\lossyWAV.exe %1 %3 %4 %5 %6 %7 %8 %9 --below --silent
ren "%~N1.lwcdf.wav" "%~N2.lwcdf.wav"
c:\programme\flac\flac.exe -b 512 -l 6 -e -m -r 2 -f --totally-silent "%~N1.lossy.wav" -o"%~N2.flac"
del "%~N1.lossy.wav"
Change the paths of lossyWAV.exe and flac.exe according to your system.
In foobar, Command Line Encoder Settings, you choose this lossyFLAC.bat as your encoder.
As parameters you use %s %d --portable -C (resp. your quality setting).
Is this working in reality for someone?
Try:
Encoder: C:\windows\system32\cmd.exe
Extension: lossy.flac
Parameters: /d /c c:\"program files"\lossyflac.bat %s %d --standard --correction
I would also suggest that you compress the correction file by adding this line to the bottom of your batch file:
c:\programme\flac\flac.exe -b 512 -l 6 -e -m -r 2 -f --totally-silent "%~N1.lwcdf.wav" -o"%~N2.lwcdf.flac"
del "%~N1.lwcdf.wav"
thanks for your help and program now it works great (with your modified batch script)
I was using CueTools lossyFLAC feature for correction files, but now it's much easier for me
Maybe all this parameters thing can be simplified?
now it works great (with your modified batch script)
+1. Thank you
lossyFLAC.bat:C:\"Program Files"\foobar2000\encoders\lossyWAV.exe %1 %3 %4 %5 %6 %7 %8 %9 --below --silent
ren "%~N1.lwcdf.wav" "%~N2.lwcdf.wav"
C:\"Program Files"\foobar2000\encoders\flac.exe -b 512 -l 6 -e -m -r 2 -f --totally-silent "%~N1.lossy.wav" -o"%~N2.flac"
del "%~N1.lossy.wav"
C:\"Program Files"\foobar2000\encoders\flac.exe -b 512 -l 6 -e -m -r 2 -f --totally-silent "%~N2.lwcdf.wav" -o"%~N2.lwcdf.flac"
del "%~N2.lwcdf.wav"
foobar2000:Encoder: C:\windows\system32\cmd.exe
Extension: lossy.flac
Parameters: C:\"Program Files"\foobar2000\encoders\lossyFLAC.bat %s %d --standard --correction
@Steve Forte Rio
Thanks for the configuration and the batch file.
I'm trying to figure out how the batch file has to look, if I'll want to join the created files? (correction file+ loosy.flac file)
Any help would be appreciated.
Thanks for the configuration and the batch file.
Thanks to
2E7AH and
Nick.C
seems I posted wrong code
looking to it now, I'll post corrected later
OK, nevermind the script, I'll post later as batch or if I can't as vbs, but the point was that merging input and correction files doesn't produce bit identical audio file
Why is that?
if someone can delete above two post please do
Here is the script:
lossyFLACcorr.batif not exist "%~n2.lwcdf.flac" goto bye
c:\"Program Files"\encoders\flac.exe -d -s "%~n2.lwcdf.flac"
c:\"Program Files"\encoders\lossywav.exe "%1" & "%~n2.lwcdf.wav" -M -Q --below --silent && del "%~n2.lwcdf.wav"
c:\"Program Files"\encoders\flac.exe -s "%~n1.lossy.wav" -o "%~n2.fla" && del "%~n1.lossy.wav"
:bye
[font= \"Courier New\"]extension: fla
parameters: /d /c c:\"Program Files"\encoders\lossyFLACcorr.bat %s %d[/font]
problem with piping double extension destination file avoided with using .fla extension for merged file
the script is just illustrative, it's not for usage - why lossyWAV.exe passes merged file to command line (so launches associated program) I don't know, as I don't know how to interpred below results, but I hope it's just mis-usage from my side:
Differences found in 11 out of 11 track pairs.
Comparing:
"C:\Users\Dejan\Desktop\Autechre\Amber\01 - Foil.flac"
"C:\Users\Dejan\Desktop\Autechre\Amber\01 - Foil.lossy.fla"
Differences found: 22797065 sample(s), starting at 0.5340590 second(s), peak: 0.0116882 at 122.5063492 second(s), 1ch
Comparing:
"C:\Users\Dejan\Desktop\Autechre\Amber\02 - Montreal.flac"
"C:\Users\Dejan\Desktop\Autechre\Amber\02 - Montreal.lossy.fla"
Differences found: 35326575 sample(s), starting at 0.2089796 second(s), peak: 0.0116882 at 101.9486621 second(s), 2ch
Comparing:
"C:\Users\Dejan\Desktop\Autechre\Amber\03 - Silverside.flac"
"C:\Users\Dejan\Desktop\Autechre\Amber\03 - Silverside.lossy.fla"
Differences found: 24584537 sample(s), starting at 0.7663039 second(s), peak: 0.0058289 at 101.6905215 second(s), 1ch
Comparing:
"C:\Users\Dejan\Desktop\Autechre\Amber\04 - Slip.flac"
"C:\Users\Dejan\Desktop\Autechre\Amber\04 - Slip.lossy.fla"
Differences found: 27736629 sample(s), starting at 0.2089796 second(s), peak: 0.0116882 at 139.8723583 second(s), 1ch
Comparing:
"C:\Users\Dejan\Desktop\Autechre\Amber\05 - Glitch.flac"
"C:\Users\Dejan\Desktop\Autechre\Amber\05 - Glitch.lossy.fla"
Differences found: 26116572 sample(s), starting at 0.1973696 second(s), peak: 0.0058289 at 73.9867347 second(s), 1ch
Comparing:
"C:\Users\Dejan\Desktop\Autechre\Amber\06 - Piezo.flac"
"C:\Users\Dejan\Desktop\Autechre\Amber\06 - Piezo.lossy.fla"
Differences found: 38026252 sample(s), starting at 0.2438095 second(s), peak: 0.0116882 at 7.8182313 second(s), 2ch
Comparing:
"C:\Users\Dejan\Desktop\Autechre\Amber\07 - Nine.flac"
"C:\Users\Dejan\Desktop\Autechre\Amber\07 - Nine.lossy.fla"
Differences found: 11415531 sample(s), starting at 0.1973696 second(s), peak: 0.0007019 at 198.4041950 second(s), 1ch
Comparing:
"C:\Users\Dejan\Desktop\Autechre\Amber\08 - Further.flac"
"C:\Users\Dejan\Desktop\Autechre\Amber\08 - Further.lossy.fla"
Differences found: 43881419 sample(s), starting at 5.8979365 second(s), peak: 0.0058289 at 50.2095692 second(s), 2ch
Comparing:
"C:\Users\Dejan\Desktop\Autechre\Amber\09 - Yulquen.flac"
"C:\Users\Dejan\Desktop\Autechre\Amber\09 - Yulquen.lossy.fla"
Differences found: 22402111 sample(s), starting at 0.2786848 second(s), peak: 0.0003357 at 85.8327211 second(s), 1ch
Comparing:
"C:\Users\Dejan\Desktop\Autechre\Amber\10 - Nil.flac"
"C:\Users\Dejan\Desktop\Autechre\Amber\10 - Nil.lossy.fla"
Differences found: 34920537 sample(s), starting at 0.2205896 second(s), peak: 0.0234070 at 359.9393650 second(s), 1ch
Comparing:
"C:\Users\Dejan\Desktop\Autechre\Amber\11 - Teartear.flac"
"C:\Users\Dejan\Desktop\Autechre\Amber\11 - Teartear.lossy.fla"
Differences found: 31764609 sample(s), starting at 0.2322222 second(s), peak: 0.0116882 at 22.4264853 second(s), 1ch
Using the command line:
lossywav ..\samples\eig.wav -C
produces two files: eig.lossy.wav and eig.lwcdf.wav in the current directory.
Using the command line:
lossywav eig.lossy.wav --merge
produces one file (if eig.lwcdf.wav is present in the same directory as eig.lossy.wav), i.e. eig.wav.
Using the command line:
comp ..\samples\eig.wav eig.wav
should result in "Files compare OK".
So, what to do with FLAC?
If lossy.flac and lwcdf.flac are converted to corresponding wavs then run:
lossyWAV.exe lossy.wav -M
equals:
[font= "Courier New"]FACT Data missing (lossy.wav)[/font]
I even downloaded source files to look for the error:
if (btrdchunk.fact.header.size=0) then lossyWAVerror('FACT Data missing (lossy.wav).',$12);
Is there obligation for some wav header?
runing:
lossyWAV.exe lossy.wav & lwcdf.wav -M
produces desired file which isn't bit identical with the original file
So, what to do with FLAC?
If you create the lossyFLAC file using piped output to FLAC then the FACT chunk goes missing because FLAC will not store it.
When creating FLAC from WAV, please remember to add "--keep-foreign-metadata" to the FLAC command line to preserve the FACT chunk. eg.:
@echo off
flac -d sample.lwcdf.flac --keep-foreign-metadata
flac -d sample.lossy.flac --keep-foreign-metadata
lossywav sample.lossy.wav -M --stdout|flac - -5 -osample.flac
del sample.lossy.wav
del sample.lwcdf.wav
well, I used your batch script which includes that switch:
c:\programme\flac\lossyWAV.exe %1 %3 %4 %5 %6 %7 %8 %9 --below --silent
if exist "%~N1.lwcdf.wav" c:\programme\flac\flac.exe -b 512 -l 6 -e -m -r 2 -f --totally-silent --keep-foreign-metadata "%~N1.lwcdf.wav" -o"%~N2.lwcdf.flac"&&del %~N1.lwcdf.wav
c:\programme\flac\flac.exe -b 512 -l 6 -e -m -r 2 -f --totally-silent --keep-foreign-metadata "%~N1.lossy.wav" -o"%~N2.flac"
del "%~N1.lossy.wav"
[edit] OK, you edited after I posted
It's working finally, thanks, but all this is too far from common user
I finally got around to trying LossyWAV this weekend as my lossless FLAC music library is too big for my netbook's hard drive. I have to say that I am really impressed. I used the parameters in Nick's signature and I have not noticed a difference between the original lossless versions and the lossy ones (although I do have tin ears).
By the way, adding the libfftw3-3.dll library file to my LossyWAV directory produced an incredible speed up in LossyWAV processing. I would highly recommend it to anyone processing a lot of files.
I got PMed about batch scripts, so I'm posting it here + to make life easier for others who want to try this and use foobar:
lossyFLAC.batgoto %1
goto end
:correction
c:\"Program Files"\encoders\lossywav %2 %4 %5 %6 %7 %8 %9 --%1 --below --silent
c:\"Program Files"\encoders\flac -b 512 -l 6 -e -m -r 2 -f --totally-silent --keep-foreign-metadata "%~n2.lwcdf.wav" -o"%~n3.lwcdf.flac"
c:\"Program Files"\encoders\flac -b 512 -l 6 -e -m -r 2 -f --totally-silent --keep-foreign-metadata "%~n2.lossy.wav" -o"%~n3.flac" && del %~n2.lwcdf.wav %~n2.lossy.wav
goto end
:merge
if not exist "%~n3.lwcdf.flac" goto end
c:\"Program Files"\encoders\flac -s -d "%~n3.flac" "%~n3.lwcdf.flac" --keep-foreign-metadata && ren "%~n3.wav" "%~n3.lossy.wav"
c:\"Program Files"\encoders\lossywav "%~n3.lossy.wav" -M --below --silent && del "%~n3.lossy.wav" "%~n3.lwcdf.wav"
c:\"Program Files"\encoders\flac -s --ignore-chunk-sizes -5 "%~n3.wav" -o"%~n3.fla"
:end
correction part produces %filename%.lossy.flac and %filename%.lossy.lwcdf.flac:
merge part produces %filename%.lossy.fla file which is identical to original file:
All tracks decoded fine, no differences found.
notes:
- because flacs aren't decoded with foobar (nevertheless temp wav is created then delated) but with flac.exe, don't forget that destination has to end in %filename% or equivalent when using merge (output file name format in converter dialog)
- if this is done in foobar media library it's good to exclude *.lwcdf.flac file types from library
- flac parameters for merged files are default foobar parameters for flac encoder, so they can be changed as desired correcting the last significant line in script
- if it's not too obvious, first parameter passed to batch file tell the script what to do (correction, merge or nothing)
have fun
By the way, adding the libfftw3-3.dll library file to my LossyWAV directory produced an incredible speed up in LossyWAV processing.
Really? As far as I know FFTW library works faster with floats (4 bytes, single precision) than doubles. If single precision is enough it should significantly speed up FFT calculation.
lossyWAV uses data type double for FFT calculations - this was due to early differences between the Matlab output and the Delphi output which were traced back to the FFT calculations.
I got PMed about batch scripts, so I'm posting it here + to make life easier for others who want to try this and use foobar
Many thanks!
I got PMed about batch scripts, so I'm posting it here + to make life easier for others who want to try this and use foobar
Thanks for your efforts from me too.
.... and from me too. The --correction / --merge parameters were implemented quite some time ago but I have not given much thought to re-integration using foobar2000, for example. Thanks for your efforts and patience in creating / testing the batch file.
I got PMed about batch scripts, so I'm posting it here + to make life easier for others who want to try this and use foobar:
Hi,
I tried your script and the "correction"-part works great. I get the "lossy.flac"- and the "lossy.lwcdf.flac"-files... all fine.
But when I try the "merge"-part I get the conversion-error (e.g.):
An error occured while finalizing the encoding process (Object not found) : "G:\Downloads\Alice In Chains - Black Gives Way To Blue\Alice In Chains - Black Gives Way To Blue - 02 Check My Brain.fla"
This is my adjusted script:
goto %1
goto end
:correction
d:\Programme\foobar2000\Encoder\lossyWAV\lossyWAV %2 %4 %5 %6 %7 %8 %9 --%1 --below --silent
d:\Programme\foobar2000\Encoder\Flac\flac -b 512 -l 6 -e -m -r 2 -f --totally-silent --keep-foreign-metadata "%~n2.lwcdf.wav" -o"%~n3.lwcdf.flac"
d:\Programme\foobar2000\Encoder\Flac\flac -b 512 -l 6 -e -m -r 2 -f --totally-silent --keep-foreign-metadata "%~n2.lossy.wav" -o"%~n3.flac" && del %~n2.lwcdf.wav %~n2.lossy.wav
goto end
:merge
if not exist "%~n3.lwcdf.flac" goto end
d:\Programme\foobar2000\Encoder\Flac\flac -s -d "%~n3.flac" "%~n3.lwcdf.flac" --keep-foreign-metadata && ren "%~n3.wav" "%~n3.lossy.wav"
d:\Programme\foobar2000\Encoder\lossyWAV\lossyWAV "%~n3.lossy.wav" -M --below --silent && del "%~n3.lossy.wav" "%~n3.lwcdf.wav"
d:\Programme\foobar2000\Encoder\Flac\flac -s --ignore-chunk-sizes -5 "%~n3.wav" -o"%~n3.fla"
:end
And here the encoder settings:
Encoder: C:\WINDOWS\system32\cmd.exe
Extension: fla
Parameters: /d /c d:\Programme\foobar2000\Encoder\lossyFLAC.bat merge %s %d
What could be the problem? And what do you mean exactly with "- ...
don't forget that destination has to end in %filename% or equivalent when using merge (output file name format in converter dialog)"? Is here the point?
Thanks in advance.
thanks to all for their feedback on the script, I redirect that to the program author and people involved in it
while I doubted if I should post here (as it is Validated News forum) or open new thread, it seems that I should have opened new thread
@Bollerkopp: I guess you run merge on original file (%filename%.flac) and not the lossy one (%filename%.lossy.flac)
line:[font= "Courier New"] if not exist "%~n3.lwcdf.flac" goto end[/font] checks if "%filename%.lwcdf.flac" exists, and if it doesn't it ends the script
%~n3 is the name part of the destination file (%d in converter) that you enter here:
I modified my converter dialog, but you'll get the point
Thanks for your answer.
But no, I used it on the lossy ones (.lossy.flac).
This is how I have done:
1. Convert an album from my Media Library (Monkey's Audio-files... Path: "F:\Musik\A-C\Alice In Chains - Black Gives Way To Blue") to ".lossy.flac" (and ".lossy.lwcdf.flac") - the correction-part.
(http://www.abload.de/image.php?img=lossyflac_correction30kv.jpg)
2. Then I put all the ".lossy.flac"-files from this folder in a playlist and select the merge-part in the converter.
In the Converter-settings under "Output files" - "Convert each track to an individual file" it looks like this:
%artist% - %album%\$if2(%artist%,unknown artist) - $if2(%album%,unknown album) $if2('CD'%discnumber%,) - [%tracknumber%] %title%)
you should run converter only on .lossy.flac files (excluding .lwcdf.flac files), and about output name format I won't repeat myself
also I just now noticed that I was merging in the source file folder, so maybe that's the problem, as I don't know of a way how foobar could give source file path to the encoder: %s gives destination path and %d gives destination name, or to put it differently - when using merge do this:
- "source track folder" must be selected for output path
- %filename% must be name format of output file
and somehow I forgot to clean up lossywav wav output so please add [font= "Courier New"]&& del "%~n3.wav"[/font] to the last line:
c:\"Program Files"\encoders\flac -s --ignore-chunk-sizes -5 "%~n3.wav" -o"%~n3.fla" && del "%~n3.wav"
Yes, I run it on the ".lossy.flac."-files only. That was not the problem. The problem was the name format of the output file. Now I changed it to "%artist% - %album%\%filename%" and it works. Sorry for overlooking it.
I adjusted the last line... now all is fine. Thank you very much for your script and the effort.
lossyWAV uses data type double for FFT calculations - this was due to early differences between the Matlab output and the Delphi output which were traced back to the FFT calculations.
Well, maybe this accuracy is redundant?
Point taken. I have modified the source (I have never really stopped modifying it, if truth be told.... Ok, so I have a "habit" ) to initialise libfftw3f-3.dll first and if found to carry out all FFT calculations using data type Single rather than Double for libfftw3-3.dll. If libfftw3f-3.dll cannot be initialised then libfftw3-3.dll will be used if it exists - if neither can be initialised then processing falls back to internal FFT routines which are Double based. This will be released at some point - I am working on a couple of other additions as well. Thanks for the prod.
Nick,
In your opinion, which lossless codec works best in conjunction with LossyWav? I know you use it with FLAC, but I don't know if that's because you prefer it or if that's simply a case of using what the Sanza supports.
I carried out a test using my 10 album test set processed at --portable --altpreset:
- FLAC: 385kbps;
- TAK: 361kbps;
- WavPack: 403kbps.
So, TAK wins the compression battle. I use FLAC, as you surmised, because of hardware compatibility.
LossyWAV 1.2.0 --standard:
WavPack -x1: 477.4 kbps
FLAC -5: 450.7 kbps
TAK -p2: 433.0 kbps
Thanks a lot guys. I really appreciate your responses.
I am going to either use Flac or Wavpack. If I go with WavPack, I will probably use -x3, as using -h or -hh increases decoding effort on the part of the computer (if I understand things correctly).
Does anyone can to rewrite the batch file for using with TAKC? (lossyTAK.bat)
I've tried but commandline encoder can not find the temp wav files (lossy and lwcdf)
here is example:
lossyTAK.batgoto %1
goto end
:correction
c:\"Program Files"\encoders\lossywav %2 %4 %5 %6 %7 %8 %9 --%1 --below --silent
c:\"Program Files"\encoders\takc -e -p2m -fsl512 -silent -overwrite -lp "%~n2.lwcdf.wav" "%~n3.tak.lwcdf.tak"
c:\"Program Files"\encoders\takc -e -p2m -fsl512 -silent -overwrite -lp "%~n2.lossy.wav" "%~n3.tak" && del %~n2.lwcdf.wav %~n2.lossy.wav
goto end
:merge
if not exist "%~n3.lwcdf.tak" goto end
copy "%~n3" "%~n3.lossy.tak" /y
c:\"Program Files"\encoders\takc -d -fim2 -silent -overwrite "%~n3.lwcdf.tak" && c:\"Program Files"\encoders\takc -d -fim2 -silent -overwrite "%~n3.lossy.tak"
c:\"Program Files"\encoders\lossywav "%~n3.lossy.wav" -M --below --silent && del "%~n3.lossy.wav" "%~n3.lwcdf.wav" "%~n3.lossy.tak"
c:\"Program Files"\encoders\takc -e -p2m -silent -lp "%~n3.wav" "%~n3.tak" && del "%~n3.wav"
:end
correction part produces %filename%.lossy.tak and %filename%.lossy.tak.lwcdf.tak:
merge part produces %filename%.lossy.tak.tak file which is identical to original file:
All tracks decoded fine, no differences found.
I've been playing with the new lossywav and also wavpack lossy. Lossywav peforms really good on very critical samples but i noticed on other 'easier' stuff its really easy to find problems on Q1. I decided to try Q2 tonight . I went for 2x5 trials.
Q2 (sorry i didn't keep log):
5/5 then 4/5 = 9/10 - added hiss on vocal
Q2.5 --portable
foo_abx 1.3.4 report
foobar2000 v0.9.6.8
2010/01/27 00:28:13
File A: C:\windows\profiles\My Documents\temp\Ivri Lider\The New People\09 - Dear Sir.flac
File B: C:\windows\profiles\My Documents\temp\09 - Dear Sir.lossy.flac
00:28:13 : Test started.
00:28:32 : 01/01 50.0%
00:28:39 : 02/02 25.0%
00:28:57 : 03/03 12.5%
00:29:24 : 04/04 6.3%
00:29:36 : 05/05 3.1%
00:33:09 : 06/06 1.6%
00:33:19 : 06/07 6.3%
00:34:16 : 06/08 14.5%
00:35:29 : 07/09 9.0%
00:36:14 : 08/10 5.5%
00:37:47 : Test finished.
----------
Total: 8/10 (5.5%)
The 1st 5 trials I was convinced and in full concentration . An added hiss on vocals no different than Q2. The 2nd half i was truck with fatigue.
I might have another go - is it significant ? 8/10 ?
Overall Q2 + 2.5 = 17/20
i decided to try wavpack @ 250 and 300k
-b250x4:
foo_abx 1.3.4 report
foobar2000 v0.9.6.8
2010/01/27 00:59:46
File A: C:\windows\profiles\My Documents\temp\Ivri Lider\The New People\09 - Dear Sir.flac
File B: C:\windows\profiles\My Documents\temp\09 - Dear Sir.wv
00:59:46 : Test started.
01:00:07 : 01/01 50.0%
01:00:16 : 02/02 25.0%
01:00:32 : 02/03 50.0%
01:00:41 : 03/04 31.3%
01:01:09 : 04/05 18.8%
01:01:16 : 05/06 10.9%
01:01:21 : 06/07 6.3%
01:01:26 : 07/08 3.5%
01:01:44 : 08/09 2.0%
01:02:23 : 09/10 1.1%
01:02:26 : Test finished.
----------
Total: 9/10 (1.1%)
-b300x4:
foo_abx 1.3.4 report
foobar2000 v0.9.6.8
2010/01/27 01:04:22
File A: C:\windows\profiles\My Documents\temp\Ivri Lider\The New People\09 - Dear Sir.flac
File B: C:\windows\profiles\My Documents\temp\09 - Dear Sir.wv
01:04:22 : Test started.
01:04:38 : 01/01 50.0%
01:04:50 : 02/02 25.0%
01:04:57 : 02/03 50.0%
01:05:11 : 02/04 68.8%
01:05:20 : 02/05 81.3%
01:05:35 : 03/06 65.6%
01:05:47 : 04/07 50.0%
01:06:24 : 05/08 36.3%
01:06:50 : 06/09 25.4%
01:07:19 : 07/10 17.2%
01:07:29 : Test finished.
----------
Total: 7/10 (17.2%)
Slight hiss @ 250k and at 300k i struggled.
The bitrate for the track :
Lossywav flac ( 369 / 381)
Wv lossy (256 / 313)
Thank you for your tests, shadowking.
Another user - unfortunately I forgot who it was - also found that --portable wasn't transparent with a specific sample.
That's why a more conservative preset scheme was introduced, which ATM has to be explicitly invoked by the --altpreset (or -t) switch.
Do you mind trying your sample using --portable --altpreset?
Other than that I'm not quite sure about your lossyWAV test methodology. Sounds a bit as if you did 5 trials for each track and queued the results for both tracks as a 10 trials result.
I think 8 trials should be done at least for each track, and the results shouldn't be mixed up.
To cover fatigue you can of course do two 5 trial tests with any of your samples and gather the results for this sample in a 10 trial list. This procedure is a 10 trial test for the sample, with a long pause between the 5th and 6th trial.
I did a total 10 trials per track and took a little rest at 5. Is Q2.5 in v1.2 same as previous versions ? I think Q2.x yields great results anyway. Quality 3 looks interesting as bitrate is half of lossless but higher than -P. Nick said extra triggers kick in at that setting. Unless one is very paranoid about bitrate , Why not quality 3 for additional headroom ? Which one is safer - Q3 or Q2.5 -altpreset ?
To make it clearer: I realize that below Q5 there is a very small risk of a deviation in noise and it doesn't bother me. If Q2 is already good my guess is Q3 will be very close to true transparency, very hard to abx which is where i want archival level encoding at.
Okay. I went strait to Q2.5 --altpreset, 10 trials without warming up.
foo_abx 1.3.4 report
foobar2000 v0.9.6.8
2010/01/27 21:13:47
File A: C:\windows\profiles\ng\My Documents\temp\Ivri Lider\The New People\09 - Dear Sir.flac
File B: C:\windows\profiles\ng\My Documents\temp\09 - Dear Sir.lossy.flac
21:13:47 : Test started.
21:14:29 : 01/01 50.0%
21:14:58 : 01/02 75.0%
21:15:14 : 02/03 50.0%
21:15:36 : 02/04 68.8%
21:16:00 : 03/05 50.0%
21:16:27 : 04/06 34.4%
21:16:57 : 05/07 22.7%
21:17:40 : 06/08 14.5%
21:18:24 : 07/09 9.0%
21:19:12 : 08/10 5.5%
21:19:22 : Test finished.
----------
Total: 8/10 (5.5%)
Thank you for your test, shadowking, great work.
If your time allows for it, it would be great if you could find the lowest -q value that makes your sample transparent, if possible both for the default and the --altpreset quality scheme.
And it would be great as well if you could upload (or give a link to) the sample.
here is example:
lossyTAK.bat
Thank you!!
Thank you for your test, shadowking, great work.
If your time allows for it, it would be great if you could find the lowest -q value that makes your sample transparent, if possible both for the default and the --altpreset quality scheme.
And it would be great as well if you could upload (or give a link to) the sample.
Sample provided:
http://www.hydrogenaudio.org/forums/index....showtopic=78244 (http://www.hydrogenaudio.org/forums/index.php?showtopic=78244)
At 6 ~ 7 secs - 'rotzehhh' has a blanket hiss. You can hear it clearly at lower Q setting
Abx @ Q3 - was too hard.
foo_abx 1.3.4 report
foobar2000 v0.9.6.8
2010/01/28 00:36:26
File A: C:\windows\profiles\ng\My Documents\temp\Ivri Lider\The New People\09 - Dear Sir.flac
File B: C:\windows\profiles\ng\My Documents\temp\09 - Dear Sir.lossy.flac
00:36:26 : Test started.
00:37:05 : 01/01 50.0%
00:37:21 : 02/02 25.0%
00:38:15 : 02/03 50.0%
00:38:22 : 03/04 31.3%
00:39:25 : 03/05 50.0%
00:39:36 : 03/06 65.6%
00:40:21 : 04/07 50.0%
00:40:30 : 05/08 36.3%
00:40:40 : 06/09 25.4%
00:40:59 : 07/10 17.2%
00:41:05 : Test finished.
----------
Total: 7/10 (17.2%)
Very interesting Shadowking. In my testing of LossyWAV at -P -t, a LossyWAV setting which I pilfered from Nick's signature, I haven't noticed my music sounding different. So either I am blessed with tin ears or I just haven't noticed it yet (maybe both).
Very interesting Shadowking. In my testing of LossyWAV at -P -t, a LossyWAV setting which I pilfered from Nick's signature, I haven't noticed my music sounding different. So either I am blessed with tin ears or I just haven't noticed it yet (maybe both).
I must stress that Q2.5 -t is not easy at all to abx , describe or explain. At lower settings i was sure in moments of concentration (q2 ~ 2.5) .Q3 felt 'impossible'. Even now i find the whole thing odd, But if it was one whole test (Q2..2.5..2.5 -t) abx would = 25/30
Thanks, for providing your sample, shadowking, and for the hint towards the issue. I'll try if I can hear the issue as well (not today cause I'm not totally well ATM).
Thanks also for testing -Q3. From your impression, as 7/10 doesn't really say something especially when looking at the log: do you think -q 3 is transparant, or do you think it isn't totally transparent, but you weren't able to ABX it?
It sounds fine however that -P -t seems to be very close to transparency, more or less the target of the portable quality level (though not totally satisfying from what we thought the -P quality is delivering, but it's good that you proved this wrong).
BTW what do you mean by saying 'even now I find the whole thing odd'?
Shadowking,
Thanks for your continued effort in ABXing lossyWAV output. I am pleased that --quality 3 is proving to be so difficult to ABX.... Out of interest, was the --quality 3 processing with or without --altpreset?
Nick.
I tried your sample, shadowking.
At -q 1 --altpreset I oould hear the issue (though I don't now if I would have noticed it if I hadn't known the spot).
At -q 2 --altpreset I still beleive I could hear it, but wasn't able to ABX it.
Well, probably my ears aren't good enough (I celebrated my 60th anniversary last year), or maybe I didn't try hard enough.
Anyway I think the issue can be classified as very subtle at -P --altpreset, but please tell us if you disagree, shadowking.
Nick, what do you think about skipping the old preset quality scheme?
With the new scheme the quality keeps closer to that of -q 5 for all the quality settings. -P takes profit of it qualitywise, and it is even more relevant for the lower quality settings the quality of which doesn't deviate too much from that of -P.
Two quality schemes aren't attractive in the long run, and IMO the new scheme is more attractive.
Maybe we should have an intermediate named quality level between --portable and --standard, corresponding to say -q 3.5 --altpreset as a proposal, now that we know -P isn't transparent. This quality level should produce transparent results with a small safety margin, so '--transparent' can be an adequate name.
(I celebrated my 60th anniversary last year)
You mean birthday. 60th anniversary would make you my parents' age.
Two quality schemes aren't attractive in the long run, and IMO the new scheme is more attractive.
Maybe we should have an intermediate named quality level between --portable and --standard, corresponding to say -q 3.5 --altpreset as a proposal, now that we know -P isn't transparent. This quality level should produce transparent results with a small safety margin, so '--transparent' can be an adequate name.
I agree that two quality schemes are not desirable and would be happy to remove one of them in the next release. However, I would have to be feeling particularly brave to call a preset "--transparent".... I'll have a think and try to come up with a possible name for the parameter. .... oh - I would probably prefer -q 3.75 rather than -q 3.5 as the quality component of the preset.
I see, you prefer -q 3.75 because it's midway between 2.5 and 5.0. As the exact value is a bit arbitrary anyway, this is a plausible choice. And a tiny bit more on the safe side.
I agree, '--transparent' wouldn't be a correct name as we can never prove this, '--expected-to-be-transparent' would be correct, but isn't a practical name, of course.
(I celebrated my 60th anniversary last year)
You mean birthday. 60th anniversary would make you my parents' age.
Yes, birthday. I thought talking about anniversary is the same thing.
Sorry i was tied up with a lot of work so i wasn't on the forum.
@halb27: Your right. Its subtle and i had to learn it @ lower settings just like wv lossy. I believe it exists @ Q2..2.5 and VERY hard to tell @ q 2.5 -t. I would say Q3 is fully transparent and had to force myself to complete that test.
@nick.c : I used just normal -q3
Just an idea about how to name the intermediate quality level -q 3.75 (--altpreset): --economic (as a short term for: a quality demand very close to that of --standard, but with a more economic bitrate).
Average bitrate for my standard test set of various old and new pop music:
-P --altpreset: 379 kbps
-q 3.75 --altpreset: 415 kbps
-S --altpreset: 445 kbps
Looks nice to me.
Could you please answer this for clarification (on my side):
For a given quality level (e.g. --standard), is --altpreset aiming to be more conservative quality-wise or is it aiming at reducing the required bitrate without perceived quality loss?
As for me, I currently use --standard for archiving (and possibly for later transcoding to lossless e.g. lame -V4) and mpc -standard for my DAPs.
Thanks for your answers.
Regards
johnb
There's two things coming with the --altpreset quality scheme:
a) For quality levels up to --standard --altpreset makes lossyWAV behave more conservative (for --standard it's nearly the same, difference is the more essential the lower the -q value). Above --standard lossyWAV reduces the overkill quality demand a bit.
b) The frequency limit of the noise analysis is lowered a bit compared to the old scheme (from 16 kHz to 15.2 kHz).
Noise analysis must be limited because otherwise in many situations no or low energy would be found in a tiny frequency region driving lossyWAV to keep all or nearly all of the bits for no good reason.
--altpreset has the effect here to make lossyWAV more efficient.
Hi,
I was "playing" around with converting some tracks with lossyWAV v1.2.0 because I'd like to transcode my music library.
Two problems I noticed with the processed tracks in Winamp v5.572:
1. The basic spectrum analyzer next to the duration display is staying "flat".
2. The milkdrop visualization plug in is not usable because the graphics are not moving anymore.
They are connected and go back to the nonresponsing spectrum analyzer I guess.
I would like to use lossyWAV but I also like to use the milkdrop visualization. Any tips or thoughts about this?
Does this plug-in work with FLAC?
Yes, it works codec independent.
I used it for years and it worked flawless. Is it possible that lossyWAV cuts certain frequencies? I'm not into that subject but I know the plugin analyses the music and generates movements depending on the music. But with the lossyWAV files it just stays "flat".
I tried converting the lossyWAV tracks to mp3 (vbr). Then the visualization responses normal again.
How does the visualisation deal with the unprocessed WAV? Similarly, the decoded WAV from the lossyFLAC file?
I decoded the lossyFLAC file to WAV with and without "--keep-foreign-metadata". Both files work fine with the plug-in.
So I guess the problem seems to be with Winamp.
Thanks for your help and sorry for the hustle.
I decoded the lossyFLAC file to WAV with and without "--keep-foreign-metadata". Both files work fine with the plug-in.
So I guess the problem seems to be with Winamp.
Thanks for your help and sorry for the hustle.
This will be fixed for Winamp 5.573/5.58/5.6 (whatever the next version is It happens when FLAC frame sizes areless than 576.
Thanks very much, Benski.
great. Thanks fro me as well!
I'll have a think and try to come up with a possible name for the parameter. .... oh - I would probably prefer -q 3.75 rather than -q 3.5 as the quality component of the preset.
How about lowering --extreme to 6.25 then and --insane to 7.5? Guess 10 is über-insane anyway... regarding that even portable is almost transparent (it certainly is for my ears). Great work btw!
Overkill quality demand of a minor degree can also be done by giving the -q values beyond 5 a less defensive meaning.
Nick does exactly this with the --altpreset scheme, but IMO there can be more to it.
Nick doesn't want to change the quality scale 0...10, and in fact there is no need for it as -q 10 can be configured internally to yield a significantly lower bitrate than with the old scheme.
Personally, i like the old scale as its simple and what I'm used to.
We could split into two categories for different people and their requirements :
Compact file sizes:
Q0 -- zero - lower quality , high chance of artifact
Q1 -- medium - medium quality, some chance of artifact
Q2 -- portable / compact - high quality, normally transparent (with small risk of artifact)
Larger files, suitable for archiving and transcoding:
Q3 -- standard - very high quality - transparent on most test samples.
Q5 -- extreme - Very high quality. Transparent with slight overkill
Q6 -- insane - Extreme high quality. Transparent with more overkill
Q7 -- Ultra - Extreme high quality. Transparent with lots of overkill
Now its clearer that a portable switch should belong to catergory 1 and a 'standard' or default to catergory 2.
Q1 or 2 are contenders for --portable and like wise Q3 could be the lossywav default and Q5 renamed to --extreme
However, Q5 is also okay as the default if we take a paranoid stance.
To simplify further with a few switches using my alternative scale;
--portable / compact = Q2
--normal / standard = Q3
--extreme = Q5
Q0 -- zero - lower quality , high chance of artifact
Q1 -- medium - medium quality, some chance of artifact
Q2 -- portable / compact - high quality, normally transparent (with small risk of artifact)
I don't think that such lq presets are necessary. LossyWAV isn't designed to deliver reasonable quality at Q1 or Q0. I suggested the presets stretching from 2.5 to 7.5 because it seems to me that the existing quality scale is too wide to be covered by resonable presets - too low at the bottom, too exesssive at the top. If this is too narrow it could be like --portable 2, --economic 3.5 --standart 5, --extreme 6.5 -- insane 8. Anyway, I think Nick should know best which presets/scale-equation is most appropriate.
The 2 groups you built, shadowking, are essential IMO:
Group 1 targeting at HQ lossy encoding, group 2 targeting at an efficient alternative to lossless.
As for the 2nd group IMO it shouldn't start below -q 5, because in this area there is the definite demand for transparency, and -q 5 is what is in line with the basic lossyWAV principle.
For group 1 there is a wide variation of quality demand what people think is acceptable. At the moment there is just 1 named quality level here (--portable), but a more stronger one (call it --economic or whatever) is in discussion.
With the --altpreset scheme there is room for a named quality level below --portable, too (call it ultra-portable or whatever).
What exact -q values to correspond with the named quality levels is a matter of taste of course, but what's done so far is quite alright for me, especially if we should get a namerd quality level below --portable.
A slight revision taking into account your input;
Category 1 - smaller files HQ lossy [ quality 2 ~ 4 ]
--compact / economy -Q2
--portable -Q2.5 -t
--high -Q3 .. 3.75
or:
--portable1 - p1 = q2
--portable2 - p2 = q2.5t
--portable3 - p3 = q3.x
Category 2 - lossless alternative [ quality 5 ~ 7 ]
--standard -Q5
--extreme -Q6
--insane -Q7
Thanks all involved for the listening tests.
My 2ct, for what it's worth:
I exclusively use the --altpreset scale, I never use lower than -q 3 (when the --impuls setting first was introduced I thought it was needed but I'm sorry not to back that up with ABX evidence). I use always the -q and not the names for presets.
You can come up with whatever names you like, just a suggestion: don't put to much meaning in those names, except where they are on the scale (low, standard-low, standard, standard-hi, hi) or something like that. What to use it for, is more or less a personal preference. (Even if it's transparent or not can be different from person to person)
Group 1 targeting at HQ lossy encoding, group 2 targeting at an efficient alternative to lossless.
It is the same thing really.
Group 1 targeting at HQ lossy encoding, group 2 targeting at an efficient alternative to lossless.
It is the same thing really.
I should have been more precise:
Group 1 targeting at HQ lossy encoding for listening purposes, group 2 targeting at an efficient alternative to lossless for archiving purposes.
I decided to try again today .
q1.5 - 7/8
2.0 - 7/8
2.0 - 8/8
3.0 - 9/10
--altpreset
q1.0 - 7/8
q2.0 - 5/10
overall --altpreset has a positive effect - but is it for all samples ?
foo_abx 1.3.4 report
foobar2000 v1.0
2010/02/14 22:36:44
File A: C:\windows\profiles\ng\My Documents\music\abx\ha\submit\09 - Dear Sir-sm.flac
File B: C:\windows\profiles\ng\My Documents\temp\q3- 09 - Dear Sir-sm.lossy.flac
22:36:44 : Test started.
22:36:56 : 01/01 50.0%
22:37:04 : 02/02 25.0%
22:37:16 : 03/03 12.5%
22:37:32 : 04/04 6.3%
22:37:58 : 04/05 18.8%
22:38:57 : 05/06 10.9%
22:39:28 : 06/07 6.3%
22:40:04 : 07/08 3.5%
22:40:16 : 08/09 2.0%
22:40:55 : 09/10 1.1%
22:45:32 : Test finished.
----------
Total: 9/10 (1.1%)
foo_abx 1.3.4 report
foobar2000 v1.0
2010/02/14 22:50:01
File A: C:\windows\profiles\ng\My Documents\music\abx\ha\submit\09 - Dear Sir-sm.flac
File B: C:\windows\profiles\ng\My Documents\temp\q2-t- 09 - Dear Sir-sm.lossy.flac
22:50:01 : Test started.
22:50:35 : 01/01 50.0%
22:50:41 : 02/02 25.0%
22:51:02 : 03/03 12.5%
22:51:11 : 03/04 31.3%
22:51:23 : 03/05 50.0%
22:51:33 : 04/06 34.4%
22:51:42 : 04/07 50.0%
22:51:49 : 04/08 63.7%
22:52:24 : 05/09 50.0%
22:52:41 : 05/10 62.3%
22:52:47 : Test finished.
----------
Total: 5/10 (62.3%)
Also playing around with this interesting new --altpreset. I tried more samples and Q1 -t is hard to abx and bitrate is similar to old q2.
... overall --altpreset has a positive effect - but is it for all samples ? ...
Nobody knows for sure, but it should be like that.
Quality demand is higher below -q 5, very significantly higher at the very low quality levels so inappropriate results for lossyWAV shouldn't exist even for low -q values.
At the --portable quality level general quality demand is still higher compared to the old scheme though bitrate is more or less the same.
The bitrate saving feature comes from the restriction of the noise analysis which stops at roughly 15.1 kHz compared to 16 kHz with the old scheme.
Low energy in small frequency areas in these high frequency regions drives the lossyWAV mechanism to save only few bits if at all for no good reason.
So in a sense the --altpreset variant takes care of quality for the better reasons - at least it is expected to do so.
If I could edit my posts, I would add this warning on posts #38 and #57:
Correction file won't be created if filename name is Unicode (or contains character not in user code page): link (http://www.hydrogenaudio.org/forums/index.php?showtopic=78695)
What would the use exactly be of degrading quality of uncompressed audio?
What would the use exactly be of degrading quality of uncompressed audio?
To compress it more, obviously
Yeah but why would someone want to do that ? I like to listen to the best quality files possible, but maybe I am alone in that
or is this for nostagists of oldschool radio and vinyl lovers l
Yeah but why would someone want to do that ? I like to listen to the best quality files possible, but maybe I am alone in that
If you cannot tell the difference between original and compressed versions then they have the same audio quality.
or is this for nostagists of oldschool radio and vinyl lovers l
I'm afraid vinyl contains more noise than LossyWAV files.
Ah, so why not just use flac and keep the quality
http://wiki.hydrogenaudio.org/index.php?ti...asked_questions (http://wiki.hydrogenaudio.org/index.php?title=Lossywav#Frequently_asked_questions)
...and with just four posts to your name, methinks you may have joined HA with mischief in mind, given your three posts in this thread.
Cheers,
David.
http://wiki.hydrogenaudio.org/index.php?ti...asked_questions (http://wiki.hydrogenaudio.org/index.php?title=Lossywav#Frequently_asked_questions)
...and with just four posts to your name, methinks you may have joined HA with mischief in mind, given your three posts in this thread.
Cheers,
David.
nope, interested why there is such thing like LossyWav, it sounded a bit like the equivalent of PuregoldImpurifier to me
Why there are such things as MP3/AAC/AC3/DTS/WMA/OGG/MPC/Wavpack lossy ?
i could never decide whether to put my flac files onto my mp3 player as they are, or encode mp3s out of them beforehand. now this comes just perfect! keep up your great work, sire!
A silly question, because I didn't really think about using lossywav before.
SInce I sometimes digitize vinyls, I thought of using lossywav on the wave files. Vinyls have lower S/N ratio than CDs, so is using lossywav on vinyls OK? Noise level introduced will still be lower than the hum and rumble from vinyls?
Should be - I would suggest using at least --standard, if not --extreme for this as it is a master copy.
I've used Lossywav on loads of vinyl. Works a treat. There's no noticeable additional noise introduced if that's what's worrying you.