Tycho started the Delphi to C++ translation of lossyWAV in August 2012. After some time getting to grips with C++ and a bit of debugging, I started to develop lossyWAV 1.4.0.
Changelog:
lossyWAV v1.4.0 02/10/2014[!--sizeo:1--][span style=\"font-size:8pt;line-height:100%\"][!--/sizeo--]
lossyWAV beta 1.3.1m 04/08/2014- Drop-dead-date now end of September 2014.
lossyWAV beta 1.3.1k 02/06/2014- Drop-dead-date now end of July 2014.
lossyWAV beta 1.3.1j2 01/04/2014- Drop-dead-date now end of May 2014.
- Crash fixed.
lossyWAV beta 1.3.1j 31/03/2014- Drop-dead-date now end of May 2014.
- Code tidy-up.
lossyWAV beta 1.3.1h 31/01/2014- Drop-dead-date now end of March 2014.
- Code tidy-up.
lossyWAV beta 1.3.1g 01/12/2013- Drop-dead-date now end of January 2014.
- Code tidy-up.
- Modifications to --shaping altfilter.
lossyWAV beta 1.3.1f 15/10/2013- Drop-dead-date still end of November.
- Bug hunt attempt #1 for non-specific crash.
lossyWAV beta 1.3.1e 07/10/2013- Drop-dead-date now end of November.
- Additions to --feedback parameter: "--feedback [n]" and "V, verbose". The addition of the numeric parameter (0.0 <= n <= 10.0) allows the user to increase the feedback sensitivity. Verbose increases the level of detail in the feedback output.
- A shorter FFT analysis has been introduced: 16 samples. This is now the first additional FFT analysis to be added (using "-a 4" or "--analyses 4"). Other FFT lengths are added in increasing numerical order.
- Bug fixes in output and some variable structural changes.
lossyWAV beta 1.3.1d 15/09/2013- Drop-dead-date now end of October.
- Additions to --feedback parameter: "r, round <n>" reduces the permitted deviation between expected added noise due to rounding and actual; "n, noise <n>" reduces the added noise level due to adaptive noise shaping; "a, aclips <n>" defines the permitted number of exceedences of the permitted adaptive noise shaping limiting level; "A, alevel <n> reduces the permitted adaptive noise shaping limiting level;
- Slight change to rounding clipping behaviour. Only clips introduced after scaling will be used when determining whether number of bits to remove should be reduced due to clipping.
lossyWAV beta 1.3.1c 04/08/2013- Drop-dead-date now end of September. Apologies for any inconvenience caused by the introduction of an expiry date for beta versions.
lossyWAV beta 1.3.1b 20/06/2013- Error in correction file re-combination (was restricted to 24-bit files) corrected.
lossyWAV beta 1.3.1a 18/06/2013- Improvements to WAVE64 and RF64 compatibility;
- Correction files work again for WAV and also WAVE64 and RF64;
- Dependency on pthreadgc2.dll removed.
lossyWAV beta 1.3.0o 11/06/2013- Introduction of WAVE64 and RF64 compatibility. lossyWAV will now read and write both formats in addition to WAV.
lossyWAV beta 1.3.0n 30/03/2013- experimental parameter --feedback introduced to modify bit removal process to include an added noise check. Seems to work well in conjunction with "--maxclips 0" or "--maxclips 1" at lower quality settings.
lossyWAV beta 1.3.0m 25/03/2013- Removed experimental new parameter --noisebtr.
- --interp-curve reinstated.
- experimental parameter --altfilter introduced to modify adaptive noise shaping method.
lossyWAV beta 1.3.0k3 08/03/2013- Introduction of experimental new parameter --noisebtr which applies a new method of detemining bits to remove. Well, I say new - SebastianG did point me in this direction *quite* some time ago. Basically, the creation of the noise shaping filter for each channel outputs a numerical value that I have finally used to determine the number of bits to remove from that codec-block channel. It even works on (non-clipping) tonal samples. It should be noted that this is a complete departure from the original method - no searching for the lowest signal in the FFT output bins. Limited tuning so far - however the presets should give approximately the same resultant FLAC output bitrate from --portable up to --insane. Below --portable, I have made the quality settings more aggressive and --extraportable results in a FLAC output bitrate of approximately 283kbit/s. This is quite a drop from the 308 to 311kbit/s previously. If anyone is prepared to spend the time on some testing, that would be very much appreciated. I think that --extraportable is a bit *too* aggressive at the moment, but that is more of a feeling than anything else.
- --interp-curve removed at this time.
- beta 1.3.0k2 issued due to omission of --noisebtr from text output parameter list (used in FACT chunk and log file).
- beta 1.3.0k3 issued due to last minute fix for bits-per-sample not equal to 16.
lossyWAV beta 1.3.0j 08/02/2013- Further experimental modification to the adaptive noise shaping routine, backed off a little but now works well with >96kHz samplerate
lossyWAV beta 1.3.0i 30/01/2013- Further experimental modification to the adaptive noise shaping routine. NB: Testing has shown that this does not work well with >96kHz samplerate!!.
- Bug-fix: now processes >16-bit properly - unexpected integer overflow discovered where floating point was thought to be used.
lossyWAV beta 1.3.0h 23/01/2013- Further experimental modification to the adaptive noise shaping routine. FLAC encode (-5 -b 512) from "-q X -i" results in 302kbit/s (compared to 309 kbit/s for vanilla --extraportable).
lossyWAV beta 1.3.0g 18/01/2013- Experimental modification to the adaptive noise shaping routine, new parameter -i, --interp-curve; adds optional cubic curve interpolation in lieu of linear interpolation when determining target spectral shape for each noise shaping filter. When encoded in FLAC (-5 -b 512) using the --extraportable preset, my 10 album test set results in 304kbit/s (compared to 309 kbit/s for vanilla --extraportable).
lossyWAV beta 1.3.0f 26/10/2012- First attempt at FFMPEG compatibility;
lossyWAV beta 1.3.0e 24/09/2012- More rounding issues found and amended;
- Output is hopefully bit identical with reference output (2nd attempt....);
lossyWAV beta 1.3.0d 18/09/2012- Bit removal chain error identified: C++ inherently rounds 0.5 differently from Delphi, Delphi uses Banker's rounding (round to even);
- Banker's rounding implemented;
Output is now bit identical with reference output (caveat: from testing so far). [edit] Found not to be at --portable. Bug hunting continues.... [/edit]
lossyWAV beta 1.3.0c 15/09/2012- Piped I/O implemented - please report problems;
- Most bugs in bit-removal chain removed - output not yet bit identical;
- Internal FFT routines optimised.
[/size]
Hi Tycho. That sounds nice.
Remember that there are the java and C# ports (although they are from older versions) that could be of help during the conversion:
jLossywav: (based on lossywav 1.1.4) http://www.hydrogenaudio.org/forums/index....st&p=645228 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=67697&view=findpost&p=645228)
C# (based on 1.0?) : http://www.hydrogenaudio.org/forums/index....showtopic=67418 (http://www.hydrogenaudio.org/forums/index.php?showtopic=67418)
Is the port done publicly, like on github or similar? This community has some very knowledgeable C++ hackers, so it might speed the process and help with finding and fixing bugs.
JAZ, Thanks, I was aware of the C# translation of version 1.0, but had missed out your java translation. Nice. There are a lot of changes in 1.3 though, and much of the work is to convert the I/O handling and runtime linking with fftw3-3 library. First step is something that compiles with gnu g++ on windows. Next would be VS2010, and then Linux/Mac g++, but that could easily someone else do.
Kohlrabi, I haven't thought about using github yet. My initial thought was just to get most of the code to compile, and then upload the code here. Useful help would be that people browsed through it and verified that the .pas and the .h/.cpp files does the same thing, but I wouldn't mind if people worked on it too.
I think that modern optimized C++ compilers (both 32 and 64 bit) are able to improve on speed a fair bit, but portability and accessibility is as important.
Hi Tycho,
How are you getting on? Impatient Inquiring minds would like to know....
It's progressing quite well. Many of the files are files are basically compiling now, but there are still some unresolved functions, e.g. the Delphi Write() function must be emulated, or all the calls to it must be rewritten. Also some of the IO routines need some work, as I mentioned.
I can post the code as it is tomorrow evening, so you can have a feel of it. Later I will come back with few questions for you, and tell a few things I've done during translation.
E.g. You have a few small functions in assembly only, like the ArcTan_Complex(). Shouldn't that return a complex number and not a float? On googling it, I found an implementation: (C++11 has it in the standard lib now)
Complex atan(Complex c)
{
Complex log_v = log( Complex(1.0 - c.imag(), c.real()) / Complex(1.0 + c.imag(), -c.real()) );
return Complex( log_v.imag() * 0.5, -log_v.real() * 0.5 );
}
The float you are returning is maybe the magnitude of the complex number returned here?
function ArcTan_Complex(const X: tDComplex): Extended;
asm
FLD X.im
FLD X.re
FPATAN
End;
According to google it is arctg(x.im/x.re) so basically it is C function atan2(x.im, x.re).
...IMHO.
Apologies - you've found some of the "dirtier" code in lossyWAV....
The ArcTan_Complex function is, as lvqcl has rightly said, equivalent to a two input atan function.
Once we have C++ version can we expect nice speed up after compiling with Intel Compiler with enabled auto vectorization and auto paralyzation? I must admit that delphi's version is rather slooow. It would be awesome if code was multithreaded and SIMD friendly.
I haven't studied enough how the data is processed, but I believe that the code must be made more reentrant, so that central functions relies exclusively on own stack data, and not global data structures (except readonly) as today. This opens the door for parallel computation if the algorithm allows for it, which I believe it does.
A simple parallelism would be to process each channel concurrently as channels are independent (even if linked then that linking of bits_to_remove would occur after all the FFT analyses have been completed for a given codec block).
A simple parallelism would be to process each channel concurrently as channels are independent (even if linked then that linking of bits_to_remove would occur after all the FFT analyses have been completed for a given codec block).
that would be a good start. 2x faster proccesing on stereo track and even more for typical 5.1 movie sound track (assuming that user has atleast quad core).
Another would be to have the FFT analyses run in parallel - each 512 sample codec block (44.1kHz / 48kHz samplerate) has 1x 1024 sample, 16x 64 sample and 32x 32 sample FFT analyses carried out on it (per channel).
[edit] can't count, apparently.... [/edit]
I have noticed that original LossyWav 1.3 does not support .wavs larger than 4GB. My wav file is 5.2GB and lossyWAV sees only 1.2 GB. LossyWav also does not support wave64 format either.
(http://i.imgur.com/q09Kw.png)
Due to the same reason pipes do not work either with large flacs
flac.exe -d "E:\Avatar.2009.BluRay.REMUX.1080p.AVC.DTS-HD.MA5.1.flac" --stdout --silent | lossywav.exe - --stdout | flac.exe - -b 512 -8 --silent -o "E\lossy.flac"
i think that new version should have something like --readtoeof or --ignorelength switch like other encoders (Aften AC3 , FhGAACEnc or OpusEnc)
A specification compliant WAV file can be no larger than 4GB (minus a few bytes for header and format information).
Maybe looking at RIFF64 or BWF would be a better way forward to cope with very large files.
Without --ignorelength switch lossyWav is useless for movie sound tracks. I can't even use pipe for direct processing.
BTW. Do you know maybe why your sources won't compile in delphi 7 pro?
You could split the soundtrack into chapters, process with lossyWAV and then recombine using foobar2000.
I don't know about Delphi 7 Pro - I have been using Turbo Delphi Explorer 2006.
Tycho,
Are there any specific compiler options that I should be using for compilation of the project?
I have downloaded the Dev-CPP IDE with MinGW 4.6.0.2 - primarily because I wanted a portable mode. Quite liking it and have started "playing" with it to get my head round C++.
On the Write() issue, would fprintf() be better? It would certainly make formatting the output much easier. I have got v0.3 to compile as far as nOutput.cpp.
Nick,
Good to hear you're progressing with c++. Yes, the old ANSI C printf (stdio.h) is in many ways easier and more compact to use, although less type safe (it normally does not check arguments in the printf statements with the formatting string). Personally I would prefer to use the current standard which is the fstream/iostream interface.
To be blunt, DEV Cpp has been dead for years, and it's Windows only (written i Delphi actually). There are better alternatives as I have mentioned earlier. For cross platform I would first recommend Qt Creator (available on Win,Linux,OS X). It is meant for Qt apps, but you may easily develop pure C++ projects without Qt and qmake. It supports many compilers, .e.g Visual Studio (Express) and GNU Mingw. You may download Qt libraries 4.8.2 (not the whole Qt SDK) for the qmake and cross platform GUI ++ libs. As a second alternative you can look at CodeLite, which is a one-man project only, then Code::Blocks which is similar.
I am going to configure Qt Creator myself with Mingw to fix the compilation issues there. It behaves different than VC++. I have currently Mingw 4.7.0 on my machine so there may be differences from 4.6.2. Don't worry about the Write() now, I will take care of that one when we get there.
This is probably information overload, so take it easy.
Updated executable later tonight - huge thanks to Tycho for getting me off my butt to delve into C++ with his translation of the Delphi source code.
A few issues found and corrected, not least the in FFT code - there were a few issues in there (int equates to FLOOR; >> is shift-arithmetic-right, not a simple shift right; log is ln, not log10....).
what is still missing in current c version vs original?
A bit of accuracy - there's a bug somewhere in the chain after the FFT analyses that still has to be tracked. Adaptive noise shaping is confirmed to be working though.
lossyWAV beta 1.3.0b attached. [edit] Superseded. [/edit]
Changelog:
Internal FFT routines now work.
To do list:
Piped input / output.
Track down accuracy error post FFT analyses.
lossyWAV beta 1.3.0b attached.
Changelog:
Internal FFT routines now work.
To do list:
Piped input / output.
Track down accuracy error post FFT analyses.
after adding pipes could you also add --ignorelength switch?
Is there any reason for custom FFT? Why not something like KISSFFT or something?
Is there any reason for custom FFT? Why not something like KISSFFT or something?
At Delphi´s development time the reason seemed to be the lack of options.
But this C++ port surely is a good opportunity to review if it remains the better choice.
And here is some small lossyWAV FFT implementation history:
lossyWAV alpha v0.3.12 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=56129&view=findpost&p=523475) - Special thanks: Dr. Jean Debord for the use of TPMAT036 uFFT & uTypes units for FFT analysis (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=56129&view=findpost&p=510729)
lossyWAV v0.6.4 RC1 (http://www.hydrogenaudio.org/forums/index.php?showtopic=60379) - Special thanks: Don Cross for the original Pascal source for the FFT algorithm used. (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=56129&view=findpost&p=536204)
lossyWAV 1.1.0b (http://www.hydrogenaudio.org/forums/index.php?showtopic=60379) - Special thanks: Don Cross for the Complex-FFT algorithm used[/url]
Change log 1.1.4b: 14/05/09 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=65499&view=findpost&p=630272): FFT (Delphi and assembler) further optimised. Radix-4 FFT implemented in assembler and Delphi and Radix-8 in Delphi. Significant speedup of Delphi FFT throughput.
I'll have a look at KissFFT - it may be faster.
I also need to try to get to grips with multi-threading to see if there is any way to speed up the processing.
There's also PFFFT library: https://bitbucket.org/jpommier/pffft (https://bitbucket.org/jpommier/pffft) But it is for single-precision floats.
I know that single precision would be faster but after trying it out earlier in the development of 1.3.0, I would much prefer to stick to double-precision.
SoX (http://sox.sourceforge.net/) uses fft4g.c from Ooura 1D FFT (http://www.kurims.kyoto-u.ac.jp/~ooura/fft.html)
Being unaware of KissFFT, I did a brief overview and noticed some factors:
- FFTW has benchmarks showing (on x64) having notably higher performance than KissFFT (the former program being version 3.3.x, the latter program's version I did not observe);
- That KissFFT was not present on all of those benchmarks, possibly having to do with limitations on certain kinds of double-precision inputs;
- That KissFFT is purported to have simpler implementation and/or structure.
I am not an expert in areas of DSP and FFT and wanted to report my impressions and conclusions. I enjoy watching the development process as I also hope to gain knowledge. I congratulate and admire the developers' efforts (and HA, of course).
- FFTW has benchmarks showing (on x64) having notably higher performance than KissFFT (the former program being version 3.3.x, the latter program's version I did not observe);
FFTW is optionally supported since lossyWAV 1.1.4c (requires libfftw3-3.dll and --fftw switch) but the main discussion here is about the internal FFT function.
Until now FFTW saved 10-20% processing time: enough to became an option but not enough adding 500Kb in the download package.
Lets wait Nick and Tycho get some benchmarks from this C++ port.
The C++ executable is *much* bigger than the Delphi one (1716kiB vs. 168kiB).
I am in the process of implementing a radix-4 IFFT while optimising the other FFT routines for speed. I think that there is some speed to be had. Also, the minGW compiler allows optimisation for various different processors and instruction sets. These do make an appreciable difference.
Main target is to get piped I/O working and to track down the accuracy bug previously mentioned.
Even though much of the point of translating to C++ was the possible optimization benefits, I think correctness is still the most important at this point. I believe there are still issues I have mentioned elsewhere that needs to be addressed, or have they been handled? Also, in getParams() an if-statement is missing:
size_t found = parameters.wavName.find_last_of("/\\");
if (found != std::string::npos)
{
parameters.WavInpDir = parameters.wavName.substr(0, found + 1);
parameters.wavName = parameters.wavName.substr(found + 1);
}
For piped IO, make sure to set input/output stream to binary mode on windows.
#ifdef _WIN32
#include <cstdio>
#include <io.h>
#include <fcntl.h>
#endif
...
if (parameter.STDINPUT || parameter.STDOUTPUT) {
#ifdef _WIN32
_setmode(_fileno(stdin), _O_BINARY);
_setmode(_fileno(stdout), _O_BINARY);
#endif
...
}
This will also make std::cin and std::cout binary, i.e. does not translate linefeed char (LF) to CRLF - leaves it as LF. Works both under g++ and VS.
As for executable size, you may try -Os compiler flag and then "strip lossyWAV.exe". With Visual Studio, the executable doesn't get very large.
Thanks for those Tycho.
I've started on piped I/O - it's taking a bit of reconfiguration but will get there in the end.
I will also go back through to check for other previously mentioned issues.
Piped I/O is now in testing phase - I processed my 10 album test set in foobar2000 without incident.
I've tracked down two problems in the bit-removal chain but am still getting slightly different results than the "reference" Delphi version. More bug-hunting to do there then.
have you decided yet what multithreading method will you choose for extra speedup?
do you even consider reading wavs to the end file? ( 4gb+ wavs )
I have not started on multi-threading yet. I will go through the debugging process until I am content that the output is a close to the output of the reference version as it can be.
I am considering adding "--ignore-chunk-sizes" functionality, but I don't yet know how best to go about it. It will have to wait until I have finished the debugging process.
[edit] English language fail.... [/edit]
i keep asking about ignore chunk size switch because i plan to add lossywav preprocessing in ripbot264.
Ah! Now it makes sense to me. In that case, I will confirm that I will attempt to develop the --ignore-chunk-sizes functionality (when I've finished initial debugging ).
great and thank you!
lossyWAV beta 1.3.0c attached to post #1 in this thread. [edit] Superseded. [/edit]
Speed comparison
Q6600@3Ghz
All read/write done on RAMDISK 2GB
flac.exe -d "G:\original.flac" --stdout --silent | G:\lossywav.exe - --stdout | G:\flac.exe - -b 512 -8 --silent -o "G:\lossy.flac"
DELPHI version - 11.48x
C++ version - 14.88x
That's certainly encouraging !
Ability to process channels independently each in separate thread should give also nice extra speedup. Especially for 6ch movie soundtracks.
I wonder if compiling with Intel Compiler we could get even higher speed than your build.
I can confirm that higher speed will be possible:
(Core 2 Duo at 1.5GHz)
Delphi : 5.75x
GCC : 7.42x
VC x86 broken : 6.73916x
VC x64 broken : 7.14685x
Delphi FFTW : 7.49x
GCC FFTW : 8.22x
VC x64 FFTW broken : 8.86619x
VC broken means a modified compile of the sources released as v05 by tycho that I've compiled with Visual Studio 2008. x86 compile is with settings: full optimizations and SSE2. (With FFTW, the output is a bit more like GCC, but is still broken.).
Oh, and the size is, between 350KB and 400KB without requiring the msvc runtimes (I've linked it statically. Else it would be around 200KB and require the VS 2008 runtimes).
@Nick: are you waiting to have a completely working version before releasing the C++ sources? I'm asking so that I don't fix things that you've already fixed.
Also, I've seen that the GCC version shows correctly the --bitdist, but --blockdist is completely different. Not sure if that shows a problem in the displaying/storage of those values, or if it is the algorithm. I guess most of the switches you added about statistics should help on debugging this port
lossyWAV beta 1.3.0d attached to post #1 in this thread. [edit] Superseded. [/edit]
lossyWAV beta 1.3.0d attached to post #1 in this thread.
Tested against lossyWAV 1.3.0 delphi version for bit identical output with internal FFT and FFTW.
-
standard quality setting:
OK (bit identical).
-
portable quality setting:
KO (not bit identical).
.... ok. Thanks for the testing - I'll go bug hunting again.
I really look forward to try this out on Linux one day. I really hope Linux drivers (especially proffessional audio interfaces) will soon be a reality so that I can use only Linux. Since installing an i3 i5 i7 patched kernel I am so impressed with Linux responsiveness. Why do I talk about Linux? Sorry guys
Tested against lossyWAV 1.3.0 delphi version for bit identical output with internal FFT and FFTW.
- standard quality setting: OK (bit identical).
It would be good to split the port into a library, and an app (if this is not being done already). Then other apps can use the library. Bear in mind that FFTW, being GPL, is not good for libraries; Ooura's fft4g is almost as fast, double-precision, and unrestricted.
I really look forward to try this out on Linux one day.
From the progress reports above, I think that day could be pretty soon!
- portable quality setting: KO (not bit identical).
Having difficulty replicating this (when the 'fact' chunk is not present, i.e. piped output).
If the 'fact' chunk is present then the file will be two bytes longer than a file processed using the reference Delphi version (the "d" in "lossyWAV 1.3.0d" and a padding byte).
I have received samples that should allow me to determine the cause of the error. I can confirm that I have duplicated the processing that shows up the discrepancies. The debugging can therefore continue....
lossyWAV beta 1.3.0e attached to post #1 in this thread.
lossyWAV beta 1.3.0e attached to post #1 in this thread.
All quality profiles tested on one single file resulted bit identical (OK).
The only remaining rouding issues that I´m seeing now are some time differences about hundredth of a second.
This difference shows off in both the wave souce´s time lenght and in several time points for "Detailed bits-to-remove data per channel per codec-block" (-d switch).
As the resulting files are identical this is just a minor display issue.
Example of different time lenght reports from my source test file:
lossyWAV 1.3.0 reports 0:32.26, lossyWAV 1.3.0e reports 0:32.27 and foobar2000 reports 0:32.267.
Thanks for the corroborative testing. I have been trying to get the times to match but have not expended too much effort there so far.
I am now at a point where I am content that the output is identical to the output of the Delphi reference version.
As previously indicated, I will be implementing a new parameter to ignore-chunk-sizes (in a manner similar to FLAC et al). This will hopefully allow use with RipBot264 for transcode audio tracks.
I am now using Code::Blocks as my IDE with MinGW 4.7.0. There are some very nice compiler switches available to me using C++ that were completely absent in Turbo Delphi, i.e. CPU targets for the compile. When I compile with -march=pentium4 the optimised executable runs approximately 13% faster than a non-optimised version (on my FX-8150) - and faster than the Delphi / IA-32 / x87 version.
Delphi / IA-32/ x87: 50.7 seconds
C++ Vanilla: 52.9 seconds
C++ Pentium4: 46.8 seconds.
why delphi version is faster than c version?
on my Q6600@3GHz c version was noticable faster.
btw. huge thanks for upcoming ignore chunk size switch.
that switch plus basic multithreading and this tool is complete!
for short stereo track single threading is not a problem but for looong 6ch tracks conversion may take really looong time.
The Delphi version (i.e. the Delphi version with significant quantities of IA-32 / x87 hand written assembly language included) is faster because of the assembly language content. A plain Delphi compile is *much* slower.
Delphi Vanilla: 4 minutes 3.2 seconds.
I should explain that my standard test (used here and in the post above) is to process my 55 sample test set (12:43.93) using FLAC | lossyWAV | FLAC with --quality extraportable and default adaptive noise shaping.
On the other hand, it may be that the executable simply performs better in an Intel CPU rather than my AMD.
single integer unit in amd fx cpus is really slow in my opinion. i won't be surprised if your fx8150 will not be faster in this task than my old overclocked Q6600
this is another reason why we need some kind of multithreading.
any news about current progress?
I've been working on speeding up the code mostly.
Recently I have managed to start the multi-threading re-write, although I have not got very far with this.
The --ignore-chunk-sizes is still on my list. I would propose to handle this the same way as handling foobar2000 output. When piping, foobar2000 sends a RIFF chunk size of -1 (0xFFFFFFFF) and a 'data' chunk size of -1 (0xFFFFFFFF). If RipBot264 were to follow this convention I think it would be best all round.
Code is getting cleaner. FFT code is re-written using operators for complex calculations. Overall, my C++ experience (thus far) has been very satisfying.
unfortunatelly ripbot264 is just a gui for other tools. something like megui. i hope that new version will work with this chain
ffmpeg -> lossywav -> ffmpeg/flac
i can not use flac.exe for decoding because it can't send large wavs via pipe.
how multithreading code will work? proccesing all channels at once or something else?
I'll work on ffmpeg compatibility.
Multi threading will probably be at the fft calculation level as input and output of processed audio is linear due to sample interleaving.
I'll see how it goes.
lossyWAV beta 1.3.0f attached to post #1 in this thread.
have you figured out how to accept pipe output from eac3to?
I will try it out and see where I get to.
Sorry for the lack of communication - I've been busy making the FFT routines thread safe and I've started on the rest of the processing steps. So far, speed has improved a bit.
I've been a bit distracted by the UK Kickstarter for Elite: Dangerous....
great! don't forget also about broken progress indicator with 4gb+ wavs
Hello everybody,
I am very new at this forum but I'm very interested in lossywav.
I'd like to mention from a general scientific view that audio compression (lossy/lossless) is a very mind expanding subject. Just the fact that people with the right tools, insight and with help of math/calculus can accomplish such things.
I would like to thank the author Nick.c and all other people contributing in this thread for making this possible.
Certainly from my point of view it is a great accomplishment to be able to shrink to smaller audio files while trying to stay as close as possible to the original.
Thank you very much for creating such a piece of software and please, if you have time and resources, keep up the good work.
I understand that Tycho has been a great contributor or fellow author with the C / C++ version.
I'm still using the Delphi 1.3.0 version, but as I understand the C++ version will have some speed improvements ?
I do have another question about the block size of FLAC. Is the block size of 512 the most optimized size ? Is it possible to use a blocksize of 256 with the extraportable setting in Lossywav or would this be too restricting to let flac store the audio in a correct manner ?
Anyway, thanks again and I will follow the development and this thread of course.
If you look back at the 1.0 thread (find it via the end of the LossyWAV Wiki entry (http://wiki.hydrogenaudio.org/index.php?title=LossyWAV)) I beileve that's where the tests were done to compare different block sizes using FLAC, I believe, as the reference codec.
At that time, testing indicated that 512 seemed to be the sweet spot, giving the flexibility to reduce bits further in short parts where the noise floor allowed. Some things have changed such as adaptive noise shaping, so it's plausible that the sweet spot might shift to 256 or 1024, though probably not very likely.
FLAC and most lossless codecs default to about 4096 sample blocks to get better compression. That's to do with the predictor working well once the first few samples of the block are encoded, but not being allowed to refer back to the last samples of the previous codec block at the start of the next block for reasons of robustness to corruption. This means the first few samples of a block require more bits to encode than the later ones.
Often quietly mastered music (some classical solo stuff) doesn't benefit much from bit-depth reduction in lossyWAV and can actually end up worse off due to the short block length, so the bitrate is increase slightly by lossyWAV.
I think TAK has a lossyWAV optimised mode that works around some of the limitations.
Hi Jan7887,
You've firstly got to thank 2Bdecided for publishing his method here (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=55522&view=findpost&p=498179). Eventually I got started on a Delphi version with lots of help from halb27. Noise shaping was next with a fixed IIR method from SebastianG. Adaptive noise shaping followed with a FIR method from SebastianG.
It's been a great hobby / project and a *huge* thief of time for about five years now - however, I am still enjoying working on the code, albeit in C++ now rather than Delphi / IA32 / x87.
When FFTW is not used, the C++ code is now faster than the assembler optimised Delphi version. When FFTW is used, the Delphi version sneaks ahead. However, with Pentium 4 C++ compiler options selected, the C++ is faster yet again.
I've been working on making the code thread safe to speed up single file processing, but been a bit sidetracked.
I'll publish a new beta soon.
On the block size, you can experiment with the FLAC encoding side of things by changing the blocksize yourself (-b [256/512/1024/etc.]) to see which is optimal for your particular audio.
Nick.
Thank you Dynamic and Nick.C for the fast response.
Also, I shamefully admit, I wasn't fully aware of a wiki page with further tests. Thanks Dynamic for the link with the wiki page.
As you might have noticed I'm rather new here, but good research and googling around can save the day.
Nevertheless I will make sure I have a valid question to ask, I mean, I will do a bit of research on my own before asking questions that I could have searched and find myself.
Thank you 2Bdecided and Halb27 and still Nick.C for making this happen and Tycho for the C++ version, very much appreciated.
Indeed the blocksize is rather a difficult beast to handle. I think that Dynamic was about right that 512 is the sweet spot for block size. I have tried various sizes, but the result is inconclusive to me. sometimes 256 seems to be allright, but anything bigger than 1024 is in my opinion a bit too much, I mean in the resulting flac size.
512 seems to be about the right size for any kind of audio.
Thanks again and cheers and I hope such innovations as Lossywav and also FLOAT16 or PFM as like to call it (Pulse Float Modulation) will continue to exist.
2nd Edit:
(The previous sentence wasn't exactly right. I mean the implementation of Float16 by Nick.C in his other project. Float16 in itself already existed of course. And I called that PFM (Pulse Float Modulation) just for fun. It probably isn't a very correct way naming it thus. Anyway, thanks and I hope I make some sense. English isn't my native language, but I think I manage quite allright.)
Cheers!,
Jan.
Tycho has kindly started the translation of lossyWAV from Delphi to C++.
Wow! Didn't see that coming...
I'll need to learn it to be able to contribute meaningfully....
If you're interested in book recommendations, try "Accelerated C++" and/or check out http://stackoverflow.com/questions/388242 (http://stackoverflow.com/questions/388242)
Kohlrabi, I haven't thought about using github yet. My initial thought was just to get most of the code to compile, and then upload the code here. Useful help would be that people browsed through it and verified that the .pas and the .h/.cpp files does the same thing, but I wouldn't mind if people worked on it too.
Please put it on github or google code with git or mercurial versioning.
It'll make distributed development
so much easier
I have downloaded the Dev-CPP IDE with MinGW 4.6.0.2 - primarily because I wanted a portable mode. Quite liking it and have started "playing" with it to get my head round C++.
If you don't want to use Microsoft tools, try a recent nightly build of the Code::Blocks IDE. But I have to say that debugging via "Visual C++ 2010 Express" is pretty sweet on a windows box.
The C++ executable is *much* bigger than the Delphi one (1716kiB vs. 168kiB).
Yeah. That's what you get for using MinGW on Windows. You might also want to check compiler options (not to include things like "-g" for the release build, for example). Finally, try "strip -s yourbinary.exe".
I guess that's also a good chance to learn something about CMake. With CMake as "build file generator" it does not matter what Toolchain/IDE developers use since they can use CMake to convert the cross-platform description "CMakeLists.txt" to a GNU Makefile or a VS2010 project file, etc etc etc. So, the nice thing about it is that one just has to maintain this cross-platform meta build script. CMake is still on my list of things to get deeper into. Unfortunately, my experience with it is rather limited at the moment.
I am in the process of implementing a radix-4 IFFT while optimising the other FFT routines for speed.
Did you profile the whole process? I would not expect the FFT to be a bottleneck here. The GNU toolchain offers some instrumentation tools you could try -- like "gprof" (GNU profiler). In order to make this work, the code needs to be compiled with the "-pg" switch if I remember correctly.
Hi Sebastian,
I was kick-started into learning C++ when Tycho so kindly started the conversion. Eventually, I started to use Code::Blocks - it's really good and I'm now using MinGW 4.7.2.
Some hair tearing and a significant amount of bug-hunting later, we have bit-exact output and some code improvements. I took the opportunity to introduce some of the optimisations that had already been included in TransPCM (same codebase as lossyWAV).
I'm working on making the processing steps thread safe at the moment.
On the FFT front, I've now implemented up to Radix-16 forward and reverse FFT code. The larger radices do make quite a significant difference in improving the processing speed. I have been using the code profiler - so simple from within Code::Blocks.
Once I have finished hacking about the core variable setup to allow threaded operation, I fully intend to use github or Google Code to allow other interested parties to contribute.
I got a bit side-tracked (again) with Float16 audio - saratoga kindly included Float16 compatibility within Rockbox. foobar2000 has been compatible for over a year now. ! I found some code that codes and decodes Float16 to float without any if/then statements - quite quick really.
Nick.
@SebastianG
Thank you very much for all your work on Adaptive Noiseshaping as implemented in Lossywav (delphi version). I saw I completely forgot to thank you
@Nick.C
Good luck with the programming on both Lossywav and the Float16 project, it is very much appreciated.
I sometimes get a comment about why I further shrink the flac files. "Why don't you just use the original flacs?" I usually get.
Well, on a desktop computer it is all fine and dandy but I'd like to listen to flac or other lossless formats on portable devices.
And as cheap as storage is, it is still not very practical to have original flacs on those devices, at least in my opinion.
Besides the subject but I'm also very interested in the Opus codec from xiph. Call me crazy, but on portable devices like phones, the opus files are quite astonishing in sound, considering the low bitrate (usually between 64 and 96 kbps for music).
Anyway, I'm going offtopic here.
Opus is very good indeed. If I was looking for very low bitrate audio for my Rockboxed Sansa Fuze I would certainly use that. Even more impressive is that it is now a standard!
Got sidetracked again - I'm going to add an option to convert any valid input audio (9-bit to 32-bit signed integer) to Float16, with or without adaptive / fixed noise-shaping. This will require the same messing about with the WAV handling code that I had to do for TransPCM. ETA is sometime early in the new year.
any progress on lossywav?
Still working on it, still distracted by the Elite: Dangerous KickStarter....
I've been experimenting with various compression levels in FLAC and -q X, and I've found that for certain tracks, -0 compresses much more efficiently than higher levels, and is practically equivalent with at least one of the tracks I tested at -8. Extraportable combined with -0 might very well make for the most overall efficient decode combination ever. Exciting stuff.
lossyWAV beta 1.3.0g attached to post #1 in this thread.
lossyWAV beta 1.3.0g attached to post #1 in this thread.
Neat! I'm getting an average of 2 to 3 kbps reduction at level 0 compression for the material I've tested so far. It also seems to average faster processing than 1.3.0a, which is what I was using previously.
I'm getting an average of 2 to 3 kbps reduction at level 0 compression for the material I've tested so far.
I've carried out a FLAC settings comparison test (based on my 55 problem sample test set) and will post the results this evening.
I did a bit of testing with my 55 problem sample set (12:43.933 of audio) processed using "-q X" and got the following results:
+------------------+---------------------+
| FLAC | Relative |
| Encoder +----------+----------+
| Setting | Size | Time |
+------------------+----------+----------+
| -8 -m -r 8 -p | 97.66% | 2187% |
| -8 -r 8 -p | 97.66% | 2089% |
| -8 -e -r 8 -p | 97.66% | 2094% |
| -8 -e -m -r 8 -p | 97.66% | 2105% |
| -8 -e -p | 97.66% | 1599% |
| -8 -p | 97.66% | 1615% |
| -8 -m -p | 97.66% | 1616% |
| -8 -e -m -p | 97.66% | 1634% |
| -6 -e -m -r 8 -p | 98.06% | 1689% |
| -7 -e -r 8 -p | 98.06% | 1694% |
| -6 -e -r 8 -p | 98.06% | 1695% |
| -7 -e -m -r 8 -p | 98.06% | 1697% |
| -4 -e -m -r 8 -p | 98.06% | 1701% |
| -7 -r 8 -p | 98.06% | 1705% |
| -7 -m -r 8 -p | 98.06% | 1710% |
| -5 -e -m -r 8 -p | 98.06% | 1723% |
| -5 -e -r 8 -p | 98.06% | 1799% |
| -7 -e -p | 98.06% | 1215% |
| -6 -e -p | 98.06% | 1220% |
| -6 -e -m -p | 98.06% | 1222% |
| -7 -m -p | 98.06% | 1222% |
| -7 -e -m -p | 98.06% | 1224% |
| -7 -p | 98.06% | 1225% |
| -5 -e -p | 98.10% | 983% |
| -5 -e -m -p | 98.10% | 1020% |
| -4 -e -m -p | 98.18% | 825% |
| -8 -r 8 | 98.36% | 368% |
| -8 -m -r 8 | 98.36% | 370% |
| -8 -e -m -r 8 | 98.36% | 374% |
| -8 -e -r 8 | 98.36% | 379% |
| -8 -e -m | 98.36% | 249% |
| -8 -m | 98.36% | 249% |
| -8 | 98.36% | 250% |
| -8 -e | 98.36% | 250% |
| -3 -e -m -r 8 -p | 98.69% | 1449% |
| -6 -e -m -r 8 | 98.80% | 294% |
| -7 -e -r 8 | 98.80% | 295% |
| -7 -r 8 | 98.80% | 295% |
| -5 -e -r 8 | 98.80% | 296% |
| -7 -e -m -r 8 | 98.80% | 296% |
| -6 -e -r 8 | 98.80% | 296% |
| -4 -e -m -r 8 | 98.80% | 298% |
| -7 -m -r 8 | 98.80% | 298% |
| -5 -e -m -r 8 | 98.80% | 318% |
| -6 -e -m | 98.81% | 174% |
| -7 -e -m | 98.81% | 175% |
| -6 -e | 98.81% | 176% |
| -7 -m | 98.81% | 177% |
| -7 -e | 98.81% | 183% |
| -7 | 98.81% | 189% |
| -3 -e -m -p | 98.82% | 605% |
| -5 -e | 98.86% | 127% |
| -5 -e -m | 98.86% | 138% |
| -4 -e -m | 98.95% | 105% |
| -3 -e -m -r 8 | 99.40% | 261% |
| -6 -m -r 8 -p | 99.42% | 201% |
| -6 -r 8 -p | 99.42% | 205% |
| -5 -r 8 -p | 99.42% | 206% |
| -5 -m -r 8 -p | 99.42% | 209% |
| -4 -m -r 8 -p | 99.42% | 215% |
| -6 -m -p | 99.42% | 137% |
| -6 -p | 99.42% | 138% |
| -5 -m -p | 99.45% | 106% |
| -5 -p | 99.45% | 108% |
| -4 -m -p | 99.51% | 87% |
| -3 -e -m | 99.55% | 71% |
| -3 -m -r 8 -p | 99.86% | 209% |
| -3 -m -p | 99.95% | 88% |
| -6 -m -r 8 | 99.97% | 28% |
| -6 -r 8 | 99.97% | 31% |
| -5 -m -r 8 | 99.97% | 32% |
| -4 -m -r 8 | 99.97% | 33% |
| -5 -r 8 | 99.97% | 33% |
| -6 -m | 99.97% | 6% |
| -6 | 99.97% | 7% |
| -5 -m | 100.00% | -1% |
+------------------+----------+----------+
| -5 | 100.00% | 0% |
+------------------+----------+----------+
| -4 -m | 100.06% | -5% |
| -3 -m -r 8 | 100.44% | 27% |
| -3 -m | 100.52% | -9% |
| -3 -e -r 8 -p | 100.54% | 678% |
| -3 -e -p | 100.69% | 279% |
| -3 -e -r 8 | 101.28% | 102% |
| -3 -e | 101.45% | 9% |
| -3 -r 8 -p | 101.76% | 78% |
| -3 -p | 101.87% | 20% |
| -3 -r 8 | 102.37% | -15% |
| -3 | 102.48% | -30% |
| -4 -e -r 8 -p | 102.59% | 846% |
| -4 -e -p | 102.74% | 403% |
| -4 -e -r 8 | 103.33% | 130% |
| -4 -e | 103.50% | 28% |
| -4 -r 8 -p | 104.08% | 85% |
| -4 -p | 104.19% | 22% |
| -4 -r 8 | 104.64% | -8% |
| -4 | 104.76% | -28% |
| -2 -e -m -r 8 -p | 108.34% | 113% |
| 0 -e -m -r 8 -p | 108.34% | 114% |
| 0 -e -m -r 8 | 108.34% | 114% |
| -2 -e -m -r 8 | 108.34% | 115% |
| -1 -e -m -r 8 | 108.34% | 115% |
| -1 -e -m -r 8 -p | 108.34% | 117% |
| -2 -e -r 8 -p | 108.34% | 118% |
| -2 -e -r 8 | 108.34% | 119% |
| -2 -r 8 | 108.50% | -4% |
| 0 -m -r 8 -p | 108.50% | -3% |
| 0 -m -r 8 | 108.50% | -3% |
| -1 -m -r 8 -p | 108.50% | -2% |
| -2 -r 8 -p | 108.50% | -1% |
| -2 -m -r 8 | 108.50% | -1% |
| -1 -m -r 8 | 108.50% | 0% |
| -2 -m -r 8 -p | 108.50% | 5% |
| -2 -e -m -p | 108.65% | -2% |
| -2 -e -m | 108.65% | -1% |
| -1 -e -m -p | 108.65% | -1% |
| 0 -e -m -p | 108.65% | -1% |
| 0 -e -m | 108.65% | -1% |
| -1 -e -m | 108.65% | 2% |
| -2 -e -p | 108.65% | 5% |
| -2 -e | 108.65% | 7% |
| 0 -m | 108.71% | -28% |
| 0 -m -p | 108.71% | -28% |
| -1 -m | 108.71% | -27% |
| -2 -m -p | 108.71% | -27% |
| -2 | 108.71% | -27% |
| -2 -m | 108.71% | -25% |
| -2 -p | 108.71% | -23% |
| -1 -m -p | 108.71% | -21% |
| 0 -e -r 8 -p | 110.94% | 30% |
| 0 -e -r 8 | 110.94% | 35% |
| 0 -r 8 -p | 111.12% | -31% |
| 0 -r 8 | 111.12% | -28% |
| 0 -e | 111.29% | -29% |
| 0 -e -p | 111.29% | -25% |
| 0 -p | 111.37% | -41% |
| 0 | 111.37% | -34% |
| -1 -e -r 8 -p | 113.83% | 34% |
| -1 -e -r 8 | 113.83% | 44% |
| -1 -r 8 -p | 114.06% | -27% |
| -1 -r 8 | 114.06% | -24% |
| -1 -e -p | 114.18% | -20% |
| -1 -e | 114.18% | -19% |
| -1 -p | 114.31% | -39% |
| -1 | 114.31% | -38% |
+------------------+----------+----------+
lossyWAV beta 1.3.0h attached to post #1 in this thread.
lossyWAV beta 1.3.0i attached to post #1 in this thread.
lossyWAV beta 1.3.0j attached to post #1 in this thread.
What is the penalty (if any) for using the -i switch? Slower encoding, higher risk of artifacts, or both? For someone not that concerned with filsesize, is the new noise shaping routine preferable to the default?
Hi Cynic,
The penalty is simply that the noise shaping is a bit more aggressive in trying to conform to the lossless audio spectrum. This saves about 1% of the resultant lossyFLAC size when compressed at --extraportable, less at higher quality levels.
I am currently working on a (very) simplistic psymodel based on masking using the Bark scale. This may be a wrong turn, but it is an option for both the classic method and the --interp-curve method of determining the basis shape of the noise spectrum.
Nick.
Out of curiousity, why does the distribution include a "gpl.txt" file? I thought it is for open source software.
When v1.40 is released, the source will be as well in a similar manner to the previous versions.
lossyWAV beta 1.3.0k attached to post #1 in this thread.
[edit] updated to beta 1.3.0k2 [/edit]
[edit2] updated to beta 1.3.0k3 [/edit2]
lossyWAV beta 1.3.0m attached to post #1 in this thread.
lossyWAV beta 1.3.0n attached to post #1 in this thread.
Thanks for your work. I'm looking forward to 1.3.0 final.
I may be late for the party, but regarding the internal FFT routines...
You might consider using FFTW's genfft (http://www.fftw.org/doc/Generating-your-own-code.html) to generate efficient FFT routine source code. genfft is a set of routines written in OCaml which generate C code for efficient FFT routines. For example, this (http://jdj.mit.edu/~stevenj/mdct_128nr.c) is a C code for 128-sample MDCT generated with genfft. These were used to generate FFTW's FFT routines, and you can use it to generate the code for lossyWAV's internal FFT routines. You can download it from here (https://github.com/FFTW/fftw3/tree/master/genfft). Contact () and I'm sure they'll gladly assist you with using it to generate code for lossyWAV.
By the way, you can read more about genfft and why FFTW is fast here (https://www.cs.drexel.edu/~jjohnson/2009-10/winter/cs650/lectures/pldi99-slides.pdf).
The best solution, however, is to not have a specified internal FFT routine, because ultimately its performance will be hardware-specific (better/worse on some hardware). You are better off completely relying on FFTW since it adapts itself to whatever hardware it's used on.
lossyWAV beta 1.3.0o attached to post #1 in this thread.
=============================================================
Hi doccolinni,
The internal FFT / IFFT routines are only used if the appropriate FFTW 32-bit DLL is not available to lossyWAV.
Nick.
does pipeing work with wave64 format? for example latest flac 1.3 -> lossywav -> latest flac 1.3
btw soon you will run out of alphabet
FLAC 1.3.0 > lossyWAV 1.3.0o > FLAC 1.3.0 works with --force-wave64-format in the first FLAC command.
Ok works like I charm
I've encoded using pipes (FLAC -> lossywav -> FLAC) 2h:41m 6 channels avatar soundtrack without any problems.
Lossywav now really needs multithreading optimalization. Using internal algo it took 40 minutes to complete task on my Q6600@3Ghz. With proper multithreading this could be reduced to 12-14 minutes.
Btw What exactly .dll does lossywav need to use FFTW? libfftw3-3.dll , libfftw3f-3.dll or libfftw3l-3.dll ?
One more thing. You forgot to include pthreadGC2.dll in package.
Lossywav now really needs multithreading optimalization.
For now, you can transcode multiple tracks in parallel.
I will be using lossywav ONLY for movie soundtracks.
Btw What exactly .dll does lossywav need to use FFTW? libfftw3-3.dll , libfftw3f-3.dll or libfftw3l-3.dll ?
libfftw3-3.dll (double precision).
One more thing. You forgot to include pthreadGC2.dll in package.
I will remove the dependency on it (multi-threading on hold at the moment).
I will remove the dependency on it (multi-threading on hold at the moment).
So I guess I will have to find a workaround for this . I'm thinking about using --skip and --until options in flac decoder. The idea is to run four tasks at the same time and each task (FLAC -> lossywav -> FLAC) will encode it's own chunk.
example
flac.exe -d "E:\Avatar.2009.BluRay.REMUX.1080p.AVC.DTS-HD.MA5.1.flac" --skip 0 --until 1000 --force-wave64-format --stdout --silent | lossywav - --stdout | flac - -b 512 -8 --silent -o "C:\chunk1.flac"
flac.exe -d "E:\Avatar.2009.BluRay.REMUX.1080p.AVC.DTS-HD.MA5.1.flac" --skip 1001 --until 2000 --force-wave64-format --stdout --silent | lossywav - --stdout | flac - -b 512 -8 --silent -o "C:\chunk2.flac"
and so on. Do you know maybe how to determine number of samples in flac file and also how to properly combine all chunks in one flac file?
Number of samples = Duration * Sample-Rate. Use metaflac --show-sample-rate to output the sample-rate of the file and --show-total-samples for total number of samples.
You can specify an exact sample reference for both --skip and --until. Sample reference should be an exact multiple of the lossyWAV block size corresponding to the sample rate of the audio. If in doubt, use a multiple of 4096;
Please ensure that the value used in conjunction with "-b" (512 in this case) is appropriate for the sample-rate of the audio. 512 for 25.6kHz <= f < 51.2kHz; 1024 for 51.2kHz <= f < 102.4kHz, etc (up to 4096);
There must be a way to join FLAC files together in this manner.... (I believe that shntool can achieve this (although not sure if it is compatible with WAVE64)).
[edits]
[more edits] 8192 should have been 4096.
Ok thanks for help !
There must be a way to join FLAC files together in this manner.... (I believe that shntool can achieve this (although not sure if it is compatible with WAVE64)).
With FLAC, I do something like this:
flac -d -c --force-raw-format --endian=little --sign=signed *.flac | flac -s -o 'album.flac' -P 8192 --best --endian=little --sign=signed --channels=2 --bps=16 --sample-rate=44100 -
so far i could not find tool which could merge flacs without re-encoding process. it really sucks that ogg vorbis can be easly losslessly splited/joined but not lossless flac format.
i still have last crazy idea. muxing flacs into .mka using mkvtoolnix and then demuxing back to .flac
lossyWAV beta 1.3.1a attached to post #1 in this thread.
lossyWAV beta 1.3.1b attached to post #1 in this thread.
lossyWAV beta 1.3.1b attached to post #1 in this thread.
I just found out that my foobar2000 v1.2.9 stops working for this version. It used to work fine.
Please help, anyone?
The parameters are:
C:\Windows\System32\cmd.exe /d /c lossyWAV.exe - --quality standard --silent --stdout|flac.exe - -b 512 -5 -f -o%d --ignore-chunk-sizes
Many thanks for the bug report. Did beta 1.3.1b function correctly with foobar2000 v1.2.8? (I upgraded to check your report and now cannot downgrade).
I will attempt to determine what has changed and create a fix.
Thanks again,
Nick.
Just attempted to run 1.3.1b and got:
%lossyWAV Error%: Program has reached expiry date.
Please contact Nick.C for a new version.
What is this?
Doesn't happen with Delphi 1.3.0
PS: Maybe it's the same issue with Musique-Rabbit?
What is this?
Doesn't happen with Delphi 1.3.0
PS: Maybe it's the same issue with Musique-Rabbit?
It probably is - my mistake. Thanks for posting the finding.
I have introduced a drop-dead-date for beta versions so that versions with potential errors in the method will expire over time.
lossyWAV beta 1.3.1c attached to post #1 of this thread.
[lossyWAV beta 1.3.1c attached to post #1 of this thread.
Yes, it works again.
Thanks, Nick.
lossyWAV beta 1.3.1d attached to post #1 in this thread.
lossyWAV beta 1.3.1e attached to post #1 in this thread.
lossyWAV beta 1.3.1e attached to post #1 in this thread.
Hey Nick,
Unfortunately, the latest version of lossyWAV seems to be faulty. It just won't work for some reason. Can you check it out when you have the time.
Thanks. Great job by the way.
Alex
Thanks for the report Alex.
Can you provide a little more detail as to the nature of the error?
Thanks.
Nick.
Thanks for the report Alex.
Can you provide a little more detail as to the nature of the error?
Thanks.
Nick.
Sure, Nick. The converter status report from Foobar 2000 is below. Please note that 1.3.1.4 works perfectly with the normal parameters (I use --quality high).
Alex
1 out of 1 tracks converted with major problems.
Source: "C:\Users\Alex Akin\Music\Main\Elbow\Asleep In The Back\01 Elbow - Any Day Now.flac"
An error occurred while writing to file (The encoder has terminated prematurely with code 1 (0x00000001); please re-check parameters) : "C:\Users\Alex Akin\Downloads\Portable Music\Elbow\Asleep In The Back\01 Elbow - Any Day Now.lossy.flac"
Additional information:
Encoder stream format: 44100Hz / 2ch / 16bps
Command line: "C:\Windows\System32\cmd.exe" /d /c C:\"Program Files"\bin\lossywav - --quality high --silent --stdout|C:\"Program Files"\bin\flac - -b 512 -5 -f -o"01 Elbow - Any Day Now.lossy.flac" --ignore-chunk-sizes
Working folder: C:\Users\Alex Akin\Downloads\Portable Music\Elbow\Asleep In The Back\
Conversion failed: The encoder has terminated prematurely with code 1 (0x00000001); please re-check parameters
Sure, Nick. The converter status report from Foobar 2000 is below. Please note that 1.3.1.4 works perfectly with the normal parameters (I use --quality high).
Alex
I tried to emulate the error with no success. It could be down any of the following (as well as being a bug in lossyWAV that has before now not deigned to rear its head):
1) No space left on drive C;
2) System date incorrectly set;
3) Either lossyWAV.exe or FLAC.exe missing from directory pointed to in command line.
Another possibility - have you tried any other tracks, and if so have you had any success with them? During the development of adaptive noise shaping, there were three John Lennon tracks from Imagine that caused a divide by zero error in the Levinson algorithm when creating the noise shaping filter and this only showed up during a mass test encode.
It's baffling. Like I said previously, only version 1.3.1.5 isn't behaving. Version 1.3.1.4 does the job smoothly, without breaking a sweat.
I've tried a range of tracks just to pinpoint the problem - all to no avail. I can confirm that there's abundant space left on drive C; system date is correct; and both lossyWAV.exe and FLAC.exe were present in folder "bin" in Program Files.
Thanks again Alex. I'll break out the bug-hunting gear and make a start.
I may be some time....
lossyWAV beta 1.3.1f attached to post #1 in this thread.
lossyWAV beta 1.3.1f attached to post #1 in this thread.
Hello Nick,
I still haven't been able to get the latest beta version of LossyWav 1.3.1 to work on any of my systems (Windows 8 and 7 respectively). Same error as the last version.
Can you confirm that the following parameters still apply:
/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
Thanks,
Alex
Try setting like this:
/d /c lossywav - -q standard --stdout 2>%d.log | flac - -b 512 -5 -f -o %d --ignore-chunk-sizes
You will get log file (hopefully with some useful error messages) in the destination directory for each song.
Try setting like this:
/d /c lossywav - -q standard --stdout 2>%d.log | flac - -b 512 -5 -f -o %d --ignore-chunk-sizes
You will get log file (hopefully with some useful error messages) in the destination directory for each song.
Thanks nu774. The error message I got is as follows:
%lossyWAV Error%: Input file: lossywav - --quality standard --silent --stdout does not exist
Can anyone make sense of it?
A bit stumped by this one....
Can you please confirm that flac.exe and lossyWAV.exe both exist in the "C:\Program Files\bin" directory?
I can confirm that both flac.exe and lossyWAV.exe are present in the "C:\Program Files\bin" directory. Interestingly, if I substitute 1.3.1f with the stable version (1.3.0.0), everything works without any problems. No error messages of any sort. For what it's worth, I'm using libFLAC 1.3.0.
Ok. Not sure that the libFLAC version is relevant as the foobar2000 command uses the executable rather than the DLL.
Which version is FLAC.exe?
Ok. Not sure that the libFLAC version is relevant as the foobar2000 command uses the executable rather than the DLL.
Which version is FLAC.exe?
FLAC.exe is the latest build - FLAC 1.3.0 (26 May 2013).
Can you please process a WAV file using lossyWAV on the command line?
Also, what CPU is in the PC?
Can you please process a WAV file using lossyWAV on the command line?
Also, what CPU is in the PC?
Strangely, it works now. I tried switching things around, using the following parameters:
/d /c C:\foobar2000\lossywav.exe - -q H --silent --stdout|C:\foobar2000\flac.exe - -b 512 -5 -f -o%d --ignore-chunk-sizes
Hopefully, this will help anyone out there experiencing the same problem. By the way, thanks a lot Nick for responding so quickly!
Glad that you managed to sort it out.
Glad that you managed to sort it out.
Hi Nick,
Any chance for a new beta version of LossyWAV with a new drop dead date?
Alex
Hi Alex,
Many apologies - my wife had a significant birthday on Friday and this weekend has been particularly hectic.
Nick.
lossyWAV beta 1.3.1g attached to post #1 in this thread.
Hi Alex,
Many apologies - my wife had a significant birthday on Friday and this weekend has been particularly hectic.
Nick.
lossyWAV beta 1.3.1g attached to post #1 in this thread.
Thanks for this, Nick. I think having a longer drop dead date like 1.3.1g does is brilliant.
By the way, congrats to you and your wife on the milestone birthday!
Thanks for this, Nick. I think having a longer drop dead date like 1.3.1g does is brilliant.
It's only two months… what's with those anyway? I'm afraid I didn't follow too closely.
The expiry date was introduced to limit the damage that an experimental function in a beta release would have, i.e. it would not be available indefinitely.
Hi
Since version 1.3.1a
I have a problem because of these parameters that I have set my foobar2000 does not work with newer versions higher than that which I have given is not unnecessarily replaced the executable file and you can not go back to the old version . I tried to make a difference in performance but still the same I jump out :
1 out of 1 tracks converted with major problems.
Source: "D:\muzyka\Flac\Radiohead - Discography 1993-2011 [FLAC]\1997 - OK Computer\04 - Exit Music (For a Film).flac"
An error occurred while writing to file (The encoder has terminated prematurely with code 1 (0x00000001); please re-check parameters) : "D:\muzyka\ass\Radiohead\OK Computer (1997)\04. Exit Music (for a Film).flac"
Additional information:
Encoder stream format: 48000Hz / 2ch / 16bps
Command line: "C:\Windows\System32\cmd.exe" /d /c c:\"Program Files (x86)"\foobar2000\encoders\lossyWAV - --quality extraportable --silent --stdout|c:\"Program Files (x86)"\foobar2000\encoders\flac --silent -b 512 -8 --ignore-chunk-sizes - -o "04. Exit Music (for a Film).flac"
Working folder: D:\muzyka\ass\Radiohead\OK Computer (1997)\
Conversion failed: The encoder has terminated prematurely with code 1 (0x00000001); please re-check parameters
What could be the problem?
Have you downloaded the latest beta version? There is now a "drop dead" date whereby beta versions expire after a certain date. Please download the latest beta and retry.
Now I use the last version 1.3.1g and the problem persists I do not know what it was?
What could be wrong?
Maybe showcase me some examples of that work? Sam I do not know where it can be a problem. Once, as was set for the first time paramatry include it did not work with one - with two persons - and written with names only worked therefore I have in this example, which I handed but here it does not help I have no idea on this.
1 out of 1 tracks converted with major problems.
Source: "D:\muzyka\Flac\Franz Ferdinand Album Discography 2004-2013 [FLAC]\Franz Ferdinand - Tonight [2009] [LIMITED] [FLAC]\CD1\05 - Twilight Omens.flac"
An error occurred while writing to file (The encoder has terminated prematurely with code 1 (0x00000001); please re-check parameters) : "D:\muzyka\ass\05 - Twilight Omens.flac"
Additional information:
Encoder stream format: 44100Hz / 2ch / 16bps
Command line: "C:\Windows\System32\cmd.exe" /d /c c:\"Program Files (x86)"\foobar2000\encoders\lossyWAV - -q X --silent --stdout|c:\"Program Files (x86)"\foobar2000\encoders\flac --silent -b 512 -8 --ignore-chunk-sizes - -o "05 - Twilight Omens.flac"
Working folder: D:\muzyka\ass\
Conversion failed: The encoder has terminated prematurely with code 1 (0x00000001); please re-check parameters
Edit:
Look at my parameters:
/d /c c:\"Program Files (x86)"\foobar2000\encoders\lossyWAV - -q X --silent --stdout|c:\"Program Files (x86)"\foobar2000\encoders\flac --silent -b 512 -8 --ignore-chunk-sizes - -o %d
The FLAC element of the command line is missing a " - " to tell the encoder to take input from STDIN.
Try moving the " - " to just after FLAC in your command line.
Nothing helps ... encoders copied to the folder foobar2000 I just change my syntax and I still have the same error ... Now the syntax looks like this:
/d /c lossyWAV - -q X --silent --stdout|flac - -b 512 -8 - -o %d --ignore-chunk-sizes
before:
/d /c lossyWAV - -q X --silent --stdout|flac -b 512 -8 --ignore-chunk-sizes -o %d
/d /c lossyWAV - -q X --silent --stdout|flac - -b 512 -8 -o %d --ignore-chunk-sizes
/d /c C:\"Program Files (x86)"\foobar2000\encoders\lossywav - -q P --silent --stdout|C:\"Program Files (x86)"\foobar2000\encoders\flac - -b 512 -5 -f -o%d --ignore-chunk-sizes
Nothing helps ... encoders copied to the folder foobar2000 I just change my syntax and I still have the same error ... Now the syntax looks like this:
/d /c lossyWAV - -q X --silent --stdout|flac - -b 512 -8 - -o %d --ignore-chunk-sizes
before:
/d /c lossyWAV - -q X --silent --stdout|flac -b 512 -8 --ignore-chunk-sizes -o %d
/d /c lossyWAV - -q X --silent --stdout|flac - -b 512 -8 -o %d --ignore-chunk-sizes
/d /c C:\"Program Files (x86)"\foobar2000\encoders\lossywav - -q P --silent --stdout|C:\"Program Files (x86)"\foobar2000\encoders\flac - -b 512 -5 -f -o%d --ignore-chunk-sizes
3 dashes, is that really your command line?
/d /c lossyWAV
- -q X --silent --stdout|flac
- -b 512 -8
- -o %d --ignore-chunk-sizes
/d /c C:\"Program Files (x86)"\foobar2000\encoders\lossywav - -q P --silent --stdout|C:\"Program Files (x86)"\foobar2000\encoders\flac - -b 512 -5 -f -o%d --ignore-chunk-sizes
Should work if both lossyWAV and FLAC are on in "C:\Program Files (x86)\foobar2000\encoders\".
Try opening a CMD window and enter the command:
"C:\Program Files (x86)\foobar2000\encoders\lossywav"
and post a copy of the output, please. (To copy output in a command window, right click in the window, select mark and click and drag to select the area of text you want to copy).
3 dashes, is that really your command line?
/d /c lossyWAV - -q X --silent --stdout|flac - -b 512 -8 - -o %d --ignore-chunk-sizes
There should only be one single dash in the FLAC element of the command line, not two. For piped processing in foobar2000 a single dash is required in the lossyWAV element of the command line.
Nothing helps ... encoders copied to the folder foobar2000 I just change my syntax and I still have the same error ... Now the syntax looks like this:
/d /c lossyWAV - -q X --silent --stdout|flac - -b 512 -8 - -o %d --ignore-chunk-sizes
before:
/d /c lossyWAV - -q X --silent --stdout|flac -b 512 -8 --ignore-chunk-sizes -o %d
/d /c lossyWAV - -q X --silent --stdout|flac - -b 512 -8 -o %d --ignore-chunk-sizes
/d /c C:\"Program Files (x86)"\foobar2000\encoders\lossywav - -q P --silent --stdout|C:\"Program Files (x86)"\foobar2000\encoders\flac - -b 512 -5 -f -o%d --ignore-chunk-sizes
I had similar problems not too long ago. Try using the following parameters:
/d /c C:\foobar2000\lossywav.exe - -q X --silent --stdout|C:\foobar2000\flac.exe - -b 512 -8 -f -o%d --ignore-chunk-sizes
In the End I managed to issue here was current path access. Although the performance of these commands through the command line with the current path "Program Files (x86)" \ foobar2000 \ encoders \ where I have other encoders. To perform but do not know why there was doing this using foobar2000. Now, I created a folder "foobar2000" on the C drive threw there encoder ect and everything works
Thanks for Your help!!!
In the End I managed to issue here was current path access. Although the performance of these commands through the command line with the current path "Program Files (x86)" \ foobar2000 \ encoders \ where I have other encoders. To perform but do not know why there was doing this using foobar2000. Now, I created a folder "foobar2000" on the C drive threw there encoder ect and everything works
Thanks for Your help!!!
Great to hear you've sorted this out. Nick: I think the Wiki needs to be updated to reflect the need for a separate foobar2000 folder on the C drive. That's the missing ingredient for making LossyWAV work - via foobar2000 at least.
I keep my encoders in a specific directory ("K:\UserData\BIN\") that is unrelated to any programs that may use them.
This directory is added to the path:
(http://s26.postimg.org/xet2goa61/Path_directory_addition.png)
and my foobar2000 converter command includes no paths to the executables, just the executable names themselves:
/d /c lossywav - --stdinname %d -F -p -w -W 127 -q X --silent --stdout|flac - --silent -b 512 -8 -o%d --ignore-chunk-sizes
So, there is no requirement for a specific directory, simply care taken when specifying the path to executables (if necessary....).
Hi there - wonderful project,
I was wondering if it was ever going to be possible to get a LINUX/MAC compilable version of lossyWAV ?
Perhaps this is something to do with the port to C from Delphi ?
Cheers
Hi weepy,
It should be - when version 1.4.0 is released, I will simultaneously release the source code. My plan is to update the Sourceforge project at the same time. Someone with the inclination and time could then modify the windows oriented elements of the code to be linux friendly.
Nick.
Did anyone do comparison between the old extraportable and the new extraportable (with feedback) setting?
I wonder if i should upgrade my LossyWAV to this new version or it's more safe to use the older version with the extraportable setting? Will i get anything in benefit? Faster encoding speed or smaller target file size?
I should say that the older extraportable setting is already very good for me. I've tried to ABX it agasint the original FLAC earlier but it was so hard for me that i eventually gave up
lossyWAV beta 1.3.1h attached to post #1 in this thread.
N.B. beta 1.3.1g will expire today.
lossyWAV beta 1.3.1j attached to post #1 in this thread.
N.B. beta 1.3.1h will expire today.
lossyWAV beta 1.3.1j attached to post #1 in this thread.
N.B. beta 1.3.1h will expire today.
Nick,
I'm getting the following error code with the newest version of lossyWAV:
1 out of 2 tracks converted with major problems.
Source: "C:\Users\Alex Akin\Music\Main\Palms\Palms\01 - Future Warrior.flac"
An error occurred while writing to file (The encoder has terminated prematurely with code 1 (0x00000001); please re-check parameters) : "C:\Users\Alex Akin\Portable\Palms\Palms\01 - Future Warrior.lossy.flac"
Additional information:
Encoder stream format: 44100Hz / 2ch / 16bps
Command line: "C:\Windows\System32\cmd.exe" /d /c C:\foobar2000\lossywav.exe - -q 5 --silent --stdout|C:\foobar2000\flac.exe - -b 512 -5 -f -o"01 - Future Warrior.lossy.flac" --ignore-chunk-sizes
Working folder: C:\Users\Alex Akin\Portable\Palms\Palms\
Conversion failed: The encoder has terminated prematurely with code 1 (0x00000001); please re-check parameters
Skipped: "C:\Users\Alex Akin\Music\Main\Palms\Palms\folder.jpg"
Version 1.3.1.8 worked just fine with the same parameters.
Alex
Problem using with Foorbar2000; was good before this revision.
Also failing here with Wine:
Unhandled exception: illegal instruction in 32-bit code (0x0043b74a).
Register dump:
CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
EIP:0043b74a ESP:00e0fb10 EBP:00000004 EFLAGS:00010202( R- -- I - - - )
EAX:00000001 EBX:00ae2620 ECX:00ae1e10 EDX:00ae1e10
ESI:00000005 EDI:0000002d
Stack dump:
0x00e0fb10: 00118de0 00a18600 00a18600 4027e3cb
0x00e0fb20: 00000069 00e0fb40 00000015 3fe00000
0x00e0fb30: 00000040 411d5d83 00a7d980 40d58880
0x00e0fb40: 0000002d 40d38800 0000002b 3ff00000
0x00e0fb50: dacbc001 3fd88b24 00000002 bf62eb8c
0x00e0fb60: 00000000 40458880 0000002a 00000200
000c: sel=0067 base=00000000 limit=00000000 32-bit r-x
Backtrace:
=>0 0x0043b74a in lossywav (+0x3b74a) (0x00000004)
0x0043b74a: lesl %ebx,%esp
Modules:
Module Address Debug info Name (17 modules)
PE 400000- c04000 Export lossywav
PE 70680000-70860000 Deferred libfftw3-3
ELF 7b800000-7ba5d000 Deferred kernel32<elf>
\-PE 7b810000-7ba5d000 \ kernel32
ELF 7bc00000-7bce4000 Deferred ntdll<elf>
\-PE 7bc10000-7bce4000 \ ntdll
ELF 7bf00000-7bf04000 Deferred <wine-loader>
ELF 7ed5d000-7ee08000 Deferred msvcrt<elf>
\-PE 7ed70000-7ee08000 \ msvcrt
ELF 7ef93000-7efd9000 Deferred libm.so.6
ELF f7392000-f7397000 Deferred libdl.so.2
ELF f73b1000-f73be000 Deferred libnss_files.so.2
ELF f73be000-f756b000 Deferred libc.so.6
ELF f756b000-f7587000 Deferred libpthread.so.0
ELF f7587000-f773e000 Dwarf libwine.so.1
ELF f773f000-f7761000 Deferred ld-linux.so.2
ELF f7761000-f7762000 Deferred [vdso].so
Threads:
process tid prio (all id:s are in hex)
00000008 (D) C:\windows\lossyWAV.exe
00000009 0 <==
0000000e services.exe
0000001d 0
0000001c 0
00000016 0
00000014 0
00000010 0
0000000f 0
00000012 winedevice.exe
0000001b 0
00000018 0
00000017 0
00000013 0
00000019 plugplay.exe
0000001f 0
0000001e 0
0000001a 0
00000022 explorer.exe
00000023 0
System information:
Wine build: wine-1.7.15
Platform: i386
Host system: Linux
Host version: 3.13.7-1-ARCH
Apologies - bug hunting commences.
.... and concluded. Amended version now available from first post in the thread as usual. Again, apologies for the crashes.
Thanks, Nick. All goes well now.
That was fast! Thanks
Apologies - bug hunting commences.
.... and concluded. Amended version now available from first post in the thread as usual. Again, apologies for the crashes.
Great job, Nick!
Thanks again for your continued efforts. LossyFLAC is the perfect companion to my Rockboxed iPod Classic
lossyWAV beta 1.3.1k attached to post #1 in this thread.
N.B. beta 1.3.1j/j2 expired on the 31st May.
Was waiting for it, thanks! I had to set the date on my computer 24h in the past in order to encode a new album yesterday. I hope we'll get to see a stable release soon!
Was waiting for it, thanks! I had to set the date on my computer 24h in the past in order to encode a new album yesterday. I hope we'll get to see a stable release soon!
Sorry for the inconvenience - I will endeavour to release 1.4.0 (and source) on or before the expiry date of beta 1.3.1k.
Nick, time to update the baby.
Thanks.
Nick,
LossyWAV stops working by the end of July. Any update for new deadline?
Thanks.
Apologies - out of town without laptop or source....
lossyWAV beta 1.3.1m attached to post #1 in this thread.
Expiry date now 30th September 2014.
Would be fun to attach the correction data to the *.lossy.flac file, in a METADATA_BLOCK_APPLICATION maybe? With transcoding software that would both:
- make use of the correction data for lossless transcoding, if present;
- and create a copy of the *.lossy.flac file without the correction data (fast operation for transfers to a DAP). FLAC Hybrid, in a single file.
Would be fun to attach the correction data to the *.lossy.flac file, in a METADATA_BLOCK_APPLICATION maybe?
That would be pointless. The .lossy.flac file together with correction data would not be smaller than the lossless .flac (in fact, it would usually be somewhat bigger). So if a lossless copy/transmission is required, it would be better to just use the lossless .flac.
I will endeavour to release 1.4.0 (and source) on or before the expiry date of beta 1.3.1k.
Any news about a 1.4.0 "stable" release? And, will it compile on Linux?
Hi skamp,
I suspect that the source as it is will not compile on Linux.
As there have been no problem reports with recent beta 1.3.1 releases, I just have to take one last look at the code before releasing version 1.4.0.
Hopefully this will be timed to coincide with the expiry of the latest beta at the end of the month.
Nick.
%lossyWAV Error%: lossyWAV beta version has reached expiry date.
*wink*
*wink*
%lossyWAV Error%: lossyWAV beta version has reached expiry date.
*wink*
*wink*
Will double check in the morning with a view to release of version 1.4.0.
Apologies again.
Are you thinking of releasing the source code so that we can compile it anyway we'd like to or/and are you thinking of supplying Linux binaries? Regards.
I will be releasing source.
I will be releasing source.
That sounds really good. Do have any idea if it will be real soon or maybe you are uncertain of when? Regards
lossyWAV v1.4.0 released, attached to post #1 in this thread along with C++ source.
lossyWAV v1.4.0 released, attached to post #1 in this thread along with C++ source.
Thank you! I will let people over at Arch Linux know about it and hopefully it ends up in their repository. Regards
Thanks a lot, Nick.
Can't wait to test (use) it!
Apparently it has to be ported before it can be used on Linux according to people developing / compiling for Arch Linux. Maybe I deserve a "duh" but I am no programmer
Apparently it has to be ported before it can be used on Linux according to people developing / compiling for Arch Linux. Maybe I deserve a "duh" but I am no programmer
…before they will agree to package it. It's usable now, with wine and caudec (http://caudec.net/).
I have a question about lossyWAV, and don't know how it works, but I really like it.
But why does it use 512 size block? can you change the block size, so standard flac no change could use it like 4096?
It's a question of adaptability. The longer the block size, the fewer the possibilities to reduce the required bits, since the reduction happens at a block level.
In fact, this is one of the reasons why generally it is recommended to use FLAC -5 instead of FLAC -8, because FLAC -8 mostly benefits of using a longer block, but that is counterproductive for lossyWav.
In fact, this is one of the reasons why generally it is recommended to use FLAC -5 instead of FLAC -8, because FLAC -8 mostly benefits of using a longer block, but that is counterproductive for lossyWav.
Although that sounds logical and reasonable, every file I tested (lossyWAV --quality High) was smaller with FLAC -8 compared to FLAC -5. Not very much (only 0.2% ... 0.3%), and of course, FLAC -5 is faster...
Edit: Above numbers resulted from a chart album. I compared that with a jazz album and the difference was even smaller (0.01% benefit for FLAC -8)
Maybe I didn't word it properly. I mean that it wasn't worth it because, as you saw, the gains were minimum. (The change of block size is not the only thing that changes from flac -5 to flac -8)
Maybe I didn't word it properly. I mean that it wasn't worth it because, as you saw, the gains were minimum. (The change of block size is not the only thing that changes from flac -5 to flac -8)
Your are right, Flac -5 is the best, testing with Flac version 1.3. I have made a test using lossyWAV on a wave. And 5 seems to be the best bet, compared to time and compression.
Compression Speed Time (in s) Space Space (in %)
=============================================================
(Wav) 1x 3432,00 816.195 KB 100%
1 434x 7,91 208.203 KB 26%
2 353x 9,72 181.593 KB 22%
3 371x 9,25 185.208 KB 23%
4 342x 10,05 198.323 KB 24%
5 228x 15,09 177.593 KB 22%
6 195x 17,60 177.591 KB 22%
7 63x 54,30 174.865 KB 21%
8 50x 68,13 174.858 KB 21%
9 50x 68,13 100.000 KB 12%
Actually Flac 4 is worse than 3.
Is it safe to assume that the result for "9" in your table is incorrect, Preuss?
Is it safe to assume that the result for "9" in your table is incorrect, Preuss?
Yes, could not edit, I'm not a developer. But you are Rights, the last line 9 is an error. I had made too many lines in Excel, forgot to delete. Please delete line 9 for me.
So, this tells me, that I don't get much out of 8 than 5.
I apologize if this has been asked before:
Does Nick's combination of "lossyWAV -q X -a 4 --feedback 4| FLAC -8" produce better audio quality than LAME MP3 at 320 kbps?
I apologize if this has been asked before:
Does Nick's combination of "lossyWAV -q X -a 4 --feedback 4| FLAC -8" produce better audio quality than LAME MP3 at 320 kbps?
You should do an ABX test to determine what is best to you since it is lossy/hybrid. I don't think I have successfully ABXed a
LossyWAV -q X using latest version 1.4 but to be sure I use higher quality settings. The files I do have successfully ABXed using earlier versions have far less annoying artifacts than some other codecs, in my opinion, since I like noise better than warbling and modulated sounding artifacts. LossyWAV is really an impressive codec!
You should do an ABX test to determine what is best to you since it is lossy/hybrid. I don't think I have successfully ABXed a LossyWAV -q X using latest version 1.4 but to be sure I use higher quality settings. The files I do have successfully ABXed using earlier versions have far less annoying artifacts than some other codecs, in my opinion, since I like noise better than warbling and modulated sounding artifacts. LossyWAV is really an impressive codec!
Thanks - the noise vs artifacts comparison is an interesting way of looking at it.
In other news... 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."
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.
In other news... 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."
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.
Please post about this experience in the lossyWAV 1.4.0 Released (http://www.hydrogenaud.io/forums/index.php?showtopic=107081) thread so that Nick.C finds out about it. For now you can use FLAC or some other format and when the WMAEncode situation is solved you can convert them losslessly to WMA, although a little more work than straight to WMA.