lossyWAV 1.3.0 released, Added noise WAV bitdepth reduction method. Options

[tycho]

FYI. I've started translating the lossyWAV 1.3.0 code to C++, in the hope that it could be better optimized (including 64 bit) and supported on all platforms. All files are roughly translated, but it's still a bit left before they compile. If anyone wants to help out, please say so. (Nick, its a straight port, so you will immediately recognize the code, even if you don't know C/C++ much).

By the way, I found an interesting article from January/April called The faster-than-fast Fourier transform, which may or may not be relevant.

[Nick.C]

Hi Tycho,

Many thanks for tackling the conversion - I have been thinking of trying to learn C++ to allow me to translate lossyWAV, but you've beaten me to it!

I will have to start learning now so that I can contribute in some way to the translation process....

Not too sure about the new transform - it seems to work for sparse signals.

Nick.

[edit] Also, I suggest that we use this thread for the development. [/edit]

This post has been edited by Nick.C: Aug 22 2012, 19:28

[LoRd_MuldeR]

What about Unicode support for lossyWAV?

http://www.mediafire.com/file/cwyb3wf9dm23...eSupport-v1.zip

[tycho]

What about Unicode support for lossyWAV?

http://www.mediafire.com/file/cwyb3wf9dm23...eSupport-v1.zip

Thanks. The C++ version should have unicode support as well.

[LoRd_MuldeR]

Thanks. The C++ version should have unicode support as well.

Haven't looked at the C++ port yet. Is it "ready for production" yet?

Also: With "should have" you mean it does have Unicode support (for Win32) or adding Unicode support (for Win32) is on the TODO list?

In the latter case, I could add Unicode support to the C++ port, if that is desired...

[tycho]

Thanks. The C++ version should have unicode support as well.

Haven't looked at the C++ port yet. Is it "ready for production" yet?

Also: With "should have" you mean it does have Unicode support (for Win32) or adding Unicode support (for Win32) is on the TODO list?

In the latter case, I could add Unicode support to the C++ port, if that is desired...

No, there's still some delphi I/O calls not translated to their fstream counterparts, and when it finally links it probably won't run at first. You'll find the discussions about this in the another thread and in the uploads section. When it comes to Unicode, it's not done so thanks for the offer. I thought maybe http://utfcpp.sourceforge.net/ could be used - seems small and nice.

This post has been edited by tycho: Aug 30 2012, 15:23

[LoRd_MuldeR]

I have hacked a Unicode support into a large number of tools that obviosuly were written for Linux only or the author didn't care about Unicode.

Since I usually don't want to change char to wchar_t everywhere (although that would be the "native" way to support Unicode on Win32), because that requires various other changes and breaks Linux compatibility (yes, you can fix that by using Preprocessor/Macro magic, but it doesn't exacatly make the code nicer), I usually go the UTF-8 route.

As an example, you may look at my UTF-8 patch that got committed into Opus-Tools:
http://git.xiph.org/?p=opus-tools.git;a=co...cf1b7c1b0e0c934

So it basically requires one extra .cpp/.h file containing a few support routines to hide the lack of UTF8 support in the Win32 API. You also need to replace fopen() with fopen_utf8().

This post has been edited by LoRd_MuldeR: Aug 30 2012, 15:45

[DonP]

No surprise here. It's known that there are some kind of signals which FLAC itself compresses very efficiently (i.e. solo piano music). Those signals can actually have a worse compression ratio when preprocessed with lossyWAV, because it forces FLAC to use a very small block size of 512 samples, thus decreasing it's efficiency (while lossyWAV can't always make up for the loss in those cases, see the small correction file).

I found this from a search after a piano track got bigger with lossywav (standard level for lossywav, and 5 for flac). Maybe there's some place to mention this caveat in the wiki article?

A similar piece on harpsichord (I guess due to more harmonics and less initial compression by flac) did shrink from 824 to 538 kb/s

[Nick.C]

Maybe there's some place to mention this caveat in the wiki article?

Sounds like a plan - it did come up in one of the development threads, but it bears repeating in the significantly more concise wiki article.

[Adagio]

A question more related to the foobar2000 converter.

Is there a way to also have the lossyWAV correction files written during the conversion to FLAC?

Simply adding --correction to the command line produces an error:

Encoder: C:\Windows\System32\cmd.exe
Extension : lossy.flac
Parameters: /d /c C:\"Program Files"\bin\lossywav - --correction --quality standard --silent --stdout|
C:\"Program Files"\bin\flac - -b 512 -5 -f -o%d --ignore-chunk-sizes

[Nick.C]

When creating correction files, --stdout cannot be used.

So, remove the

CODE

--stdout|C:\"Program Files"\bin\flac - -b 512 -5 -f -o%d --ignore-chunk-sizes

portion and replace it with

CODE

-C --stdinname "%d"

This will create WAV files rather than FLAC files. To compress to FLAC, import to foobar2000 and create a custom FLAC converter with "--keep-foreign-metadata" in the command line. If "--keep-foreign-metadata" is omitted then the files will not be able to be reinstated back to lossless as the 'FACT' chunks will be lost.

This post has been edited by Nick.C: Feb 23 2013, 13:56