Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Yalac - Comparisons (Read 210035 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Yalac - Comparisons

Reply #325 –
Quote
' date='Oct 1 2006, 19:28' post='436819']
Quote from: TBeck on
V0.12 is done
I have only one thing I can say : WICKED

Huh...

Why? Sorry, if i should have missed something.

Yalac - Comparisons

Reply #326 –
"Wicked" means "superb".

Werd dawg.

Edit: Thomas, you should probably add http://www.urbandictionary.com/ to your list of translators.

Urban Dictionary's definition of Wicked.
I'm on a horse.

Yalac - Comparisons

Reply #327 –
Quote from: Synthetic Soul on
"Wicked" means "superb".

Werd dawg.

Shame on google translation (or my inability to use it right...)! It said "gemein" (vulgarity, meanness).

Thanks

  Thomas

Yalac - Comparisons

Reply #329 –
Code: [Select]
TAKC -mode infile [outfile] [-px -wx -lx -w -overwrite -cx]

-mode      -e encode, -d decode, -t test decode, -te test encode
infile     specify file or directory (Dir\*) to be processed
outfile    specify output file or directory (Dir\*)
-px        select encoder preset x
             T/F/L/N/H/E or 0-5 for Turbo/Fast/Light/Normal(default)/High/Extra
             Append M to increase the evaluation level to the Maximum:
               -p0m = Preset 0 with evaluation level Max
               -p0s = Preset 0 with evaluation level Standard = -p0 (default)
-wx        save (encoding)/restore(decoding) non-audio wave file data
-lx        select log file level x
             0 = no log file (default)
             1 = log compression results
             2 = log compression results and encoder diagnostics
-w         wait for enter key when finished
-overwrite overwrite existing wave files when decoding
-cx        test case x

A couple of suggestions (feel free to ignore):
  • WARNING: Slightly anal.  It is slightly confusing to use -px, -wx, -cx and -lx where the 'x' in -px. -cx and -lx means a variable, but in -wx it does not.  It may be better to use a format like -pX, -p<X>, -p?, or -p#.
  • I would be tempted to include and extract additional WAVE data by default, and provide the option to exclude from compression, and perhaps from decompression (although if they have been encoded they are most likely required).  TAK is a lossless compressor, and users may not understand why data has been lost during the compression/decompression process.  WavPack includes by default (with the option to ignore) IIRC, and FLAC excludes by default (with no option to include) IIRC.  I seem to remember FLAC's stance confusing some people.  I say, save yourself the bother.  Maybe there is a good reason to remove this data?  I assume WAVE files created by EAC or fooabr for example would not contain additional RIFF chunks?

I should be posting my results for the normal compression stats this evening (in 10 hours or so).

Do you (or anyone else) have any suggestions how to get additional data into a WAVE file?  I have no experience with RIFF chunks.
I'm on a horse.

Yalac - Comparisons

Reply #330 –
Quote from: Synthetic Soul on
A couple of suggestions (feel free to ignore):

Never! Thanks.

It's funny: After the release i played a bit with TAK and stumbled exactly over those issues!

Quote from: Synthetic Soul on
WARNING: Slightly anal.  It is slightly confusing to use -px, -wx, -cx and -lx where the 'x' in -px. -cx and -lx means a variable, but in -wx it does not.  It may be better to use a format like -pX, -p<X>, -p?, or -p#.

I would like p<X> or -p#. Possibly -p# is better, because <X> could be misunderstood as optional parameter.

BTW: What's a good way to specify enabled/disabled? Is 0/1 ok: -wx0 or -wx1?
Quote from: Synthetic Soul on
I would be tempted to include and extract additional WAVE data by default, and provide the option to exclude from compression, and perhaps from decompression (although if they have been encoded they are most likely required).  TAK is a lossless compressor, and users may not understand why data has been lost during the compression/decompression process.  WavPack includes by default (with the option to ignore) IIRC, and FLAC excludes by default (with no option to include) IIRC.  I seem to remember FLAC's stance confusing some people.  I say, save yourself the bother.  Maybe there is a good reason to remove this data?  I assume WAVE files created by EAC or fooabr for example would not contain additional RIFF chunks?

Yes, it should be always turned on by default!  It's most important purpose is to avoid irritation of newbies in lossless compression, who would doubt, that TAK is really lossless, if the decompressed file is a bit different.

Possibly i disabled it, because i am not sure yet, if it always works...

And you sometimes will have to disable it, if you want to decode a severely damaged file.

Quote from: Synthetic Soul on
I should be posting my results for the normal compression stats this evening (in 10 hours or so).

Great!
Quote from: Synthetic Soul on
Do you (or anyone else) have any suggestions how to get additional data into a WAVE file?  I have no experience with RIFF chunks.

Some audio editors have an option to include meta data, that's at least true for the good old CoolEdit.

Yalac - Comparisons

Reply #331 –
Quote from: TBeck on
Quote from: Synthetic Soul on

Do you (or anyone else) have any suggestions how to get additional data into a WAVE file?  I have no experience with RIFF chunks.

Some audio editors have an option to include meta data, that's at least true for the good old CoolEdit.

The same goes for at least Wavelab, Soundforge, Audition (former Cooledit Pro) and Samplitude.

Yalac - Comparisons

Reply #332 –
Quote from: TBeck on
I would like p<X> or -p#. Possibly -p# is better, because <X> could be misunderstood as optional parameter.

BTW: What's a good way to specify enabled/disabled? Is 0/1 ok: -wx0 or -wx1?
Yeah, -p# looks good.

Personally, I would suggest that -wx is enabled, and no switch is disabled, e.g.:

TAKC.EXE -e -wx file.wav <- Enabled, ignore extra data

TAKC.EXE -e file.wav <- Disabled, include extra data

If you use -wx0 and -wx1 one of them needs to be the default (let's say -wx0).  If that is the case you don't really need it, leaving you with only one (-wx1) that makes a difference.  In that case -wx1 may as well just be -wx... IM(not so)HO.

Quote from: TBeck on
And you sometimes will have to disable it, if you want to decode a severely damaged file.
Ah, very good point.

Quote from: TBeck on
Some audio editors have an option to include meta data, that's at least true for the good old CoolEdit.
OK, thanks.  I'll take a look at Goldwave and Audacity (the two I have) for now.

Quote from: Emanuel on
The same goes for at least Wavelab, Soundforge, Audition (former Cooledit Pro) and Samplitude.
Thanks for the info.
I'm on a horse.

Yalac - Comparisons

Reply #335 –
Quote from: Synthetic Soul on
TAK vs The Rest of The World
http://synthetic-soul.co.uk/comparison/lossless/

TAK vs Yalac
http://synthetic-soul.co.uk/comparison/tak/

Thanks!

Short analysis:

- As expected no big surprises.
- Not as much improvement for TURBO and NORMAL as on my file sets, but also no significant speed penality.
- I find the comparison less confusing (too many options/presets) after the removal of evaluation level EXTRA. And on your system evaluation MAX is only 2 times slower than evaluation STANDARD (Default), hence no big gap that had to be filled by another evaluation level.

For me this final preset configuration looks well balanced.

Yalac - Comparisons

Reply #336 –
For this corpus it out-performs Flake -12 and FLAC 1.1.2_CVS as well.

Code: [Select]
                                     Encode          Decode
Encoder Setting    Compression    CPU+IO   CPU    CPU+IO   CPU
==============================================================
TAK Turbo              64.890%       76x  103x       79x  113x
Flake -12 -v 1         65.259%        7x    7x       70x   84x
Flake -12              65.368%        7x    7x       69x   83x
FLAC 1.1.2_CVS -9      65.528%        6x    6x       71x   92x


Quote from: TBeck on
- As expected no big surprises.
- Not as much improvement for TURBO and NORMAL as on my file sets, but also no significant speed penality.
- I find the comparison less confusing (too many options/presets) after the removal of evaluation level EXTRA. And on your system evaluation MAX is only 2 times slower than evaluation STANDARD (Default), hence no big gap that had to be filled by another evaluation level.

For me this final preset configuration looks well balanced.
I agree, it's all looking very balanced, and quite easy to judge a preset of choice.
I'm on a horse.

Yalac - Comparisons

Reply #337 –
I have made some small tests using the -wx switch, which stores and retrieves meta data.

I created two 30s wave files, "sine.wav" and "noise.wav", using Audacity's "Generate" functions.  I then used Goldwave to add various meta data to the files (view dialogue).

I encoded the files using all presets with the -wx switch.  I then decoded them all using the -wx switch, and, as usual with my scripts, I compared the MD5 of the decoded file with that of the source.  In all cases they matched.

I then dragged some of the decoded files into Goldwave to check that the meta data could be viewed, which it could.

Finally, I decoded some files without using the -wx switch, dragged those into Goldwave and confirmed that the meta data was missing.

So, in conclusion, it all worked as expected.

Looking at a file in a hex editor the meta data has been stored at the end of the file, and is using chunk IDs as per this document.
I'm on a horse.

Yalac - Comparisons

Reply #338 –
Quote from: Synthetic Soul on
...
I encoded the files using all presets with the -wx switch.  I then decoded them all using the -wx switch, and, as usual with my scripts, I compared the MD5 of the decoded file with that of the source.  In all cases they matched.

I then dragged some of the decoded files into Goldwave to check that the meta data could be viewed, which it could.

Finally, I decoded some files without using the -wx switch, dragged those into Goldwave and confirmed that the meta data was missing.

So, in conclusion, it all worked as expected.
...

What a work! Thanks so much!

Quote from: Synthetic Soul on
Looking at a file in a hex editor the meta data has been stored at the end of the file, and is using chunk IDs as per this document.

Fine! I must admit, that i never tried it with metadata located at the end.

And to be honest: I am still using my absolutely minimalistic wave parser. With -wx it simply looks for the first audio data chunk and handles anything else as black box and simply copies it into the appropriate meta data structure.

That's also the reason, why you may have to remove the -wx switch when decoding damaged files: If some frames at the end of the file are missing, TAK has to update the audio data size in the wave file header. But because the header generated with -wx is only a black box for TAK, it does not know how to do this right.

Something more problematic: I am not sure, but i think, that it is possible to create a wave file with more than one audio data chunk. Currently TAK would simply drop any audio data behind the first chunk! Very bad, but i never have seen a file witch such a structure.

You may notice, that i don't know really much about the wave file format...

Yalac - Comparisons

Reply #339 –
V0.13 is done

(but still needs some testing performed by myself)

Encoder:

- Support for any sample rate from 8000 to 96000 Hz.
- Support for 8-Bit samples. Not too important, but TAK should be quite efficient here.

Presets:

I call this the really, really, really, really... final configuration! You may have noticed, that i have appended a fourth (only 3 in V0.12) "really". You may read it as final preset configuration V4...

- Preset LIGHT is gone!
- Preset NORMAL is basically preset LIGHT of V0.12, but with channel decorrelation option 'Check both' enabled and 'Partitition resolution' increased to 128. Encoding speeed should be closer to old LIGHT than old NORMAL.
- EXTRA enables 'Bitcoder/Optimize choice' and encodes a bit slower. Tiny compression increase of about 0.05 percent.

How comes? I found the compression difference between FAST/LIGHT, LIGHT/NORMAL and NORMAL/HIGH too small and wanted a faster default preset (NORMAL). Encoding speed resolution is nevertheless quite good: On my system NORMAL is about 1.6 times slower than FAST and HIGH about 1.7 times slower than NORMAL. Same ratio for EXTRA vs. HIGH.

Functionality:

- GUI version supports an user defined output directory.
- Overwrite option for encoding and decoding.
- More and better error messages and warnings for screen and log file protocol.
- Summary of errors and warnings at the end of the protocol.
- Better error handling: The program should only be aborted, if a file io error occurs (i am working on this too).
- Warning, if the meta data of a wave file is too big to be stored into the TAK file.
- Added log file generation for decoding.
- Possibility to abort encoding/decoding.
- Saving and restoring of non-audio- (Meta-) wave file data is now enabled by default.

Not too many news here but nevertheless much work. I had to rewrite considerable parts of my code to improve the error handling and to prepare a later translation to C (I had been using exceptions for the error handling, which are not beeing supported by standard C).

File format:

- Meta data stores the preset used for compression.
- Removed any configuration option for the stream format: Seek point interval, info-frame-interval and seek-frame-interval.
- Seekpoint interval is now fixed to 1 second. Needs very little space and allows for very fast seeking.
- Info-Frame interval is now fixed to 2 seconds. It's only important for the start up latency when linking to a running stream.
- Now every frame is a Seek-Frame. Allows for fast seeking even if the decoder can't use the seek table. Compression penality ranging from 0.03 percent for TURBO and 0.01 percent for EXTRA.
- Many corrections of the stream format. Hope it's still working...

Command line:

- Now files have to be specified as last parameters on the command line.
- By default, log files are no longer beeing appended to existing ones. You have to append an 'A' to the log file option (-L1A) to enable the appending.
- You can specify most of the encoder options available in the GUI version on the command line to overwrite the default settings of the selected preset.
- Option to control saving and restoring of non-audio- (Meta-) wave file data is now -wm (wave file meta data) instead of -wx.

Release:

I hope to send the new version to the following testers within the next 2 days (this time i may need a bit more time to verify the program function, because there are so many modifications of the file format):

Destroid
JohanDeBock
Josef Pohm
Robby
Synthetic Soul

Only reason for this selection: I haven't heard from the other testers within the last 10 days and i don't want to fill their mail box with new versions they possibly currently don't need.

Any of them can sent me an email anytime, and i will sent the current version.

What should be tested:

- Comparison with V0.12: Performance of new NORMAL.
- Verify, that the decoded files match the original. Too many changes to be sure, that everything is still ok...
- Is the GUI ok? Is there any essential option missing?
- Is the command line interface ok?
- After the implementation of the abort option (ESCape key) for the command line, the program sometimes paused without any reason. A keypress was necessary to continue. This only happened, when i started the program from my development framework. Possibly this has only been caused by the debugger, but please tell me, if you should have similar trouble.

Plans for V 0.14:

- Possibly some final modifications of the encoder data stream. Should not affect the performance.
- Final examination of the container format to be sure, that i haven't forgot something.
- Bug fixes.

Well, this should be the last announcement of a new version in this thread. For 0.14 i will open a new thread "TAK - Preparing the public release". Then (!!!) i will ask for 5 to 10 new testers who want to try TAK for real work.

I would be happy to release TAK in early december. Unfortunately i will not have much time to work on TAK within the next four weeks. But i will do my very best!

  Thomas

Yalac - Comparisons

Reply #340 –
BTW, a lot of GNU projects use a syntax like +wx to mean disabled (opposite of -wx, kind of). Alternately a named switch like -wx-off.

I haven't followed this since June, the recent results are quite stunning. =o

Yalac - Comparisons

Reply #341 –
Quote from: TBeck on
V0.13 is done

And on the way.

Quote from: TBeck on
- After the implementation of the abort option (ESCape key) for the command line, the program sometimes paused without any reason. A keypress was necessary to continue. This only happened, when i started the program from my development framework. Possibly this has only been caused by the debugger, but please tell me, if you should have similar trouble.

Unfortunately i had to remove this option. It also happened without my debugger running in the background. The module i am using for console input is the only source code in Tak, that i have not written by myself. Therefore it will be a bit more difficult to find the bug. But this option anyhow seems not too important for me.

Possibly i am having trouble sending Mails. And sometimes they are beeing caught by spam filters...

Be assured, that until now i have answered any mail regarding TAK.

  Thomas

Yalac - Comparisons

Reply #343 –
Quote from: Synthetic Soul on
TAK vs The Rest of The World
http://www.synthetic-soul.co.uk/comparison/lossless/

TAK 0.12 vs TAK 0.13
http://www.synthetic-soul.co.uk/comparison/tak/

Thanks. That was very fast!

Comments:

- As expected we see a compression penality of 0.01 to 0.03 percent caused by the extensions of the streaming format.
- I like the new NORMAL preset. It's faster than the old one, the compression difference to FAST and HIGH is bigger and the encoding speed ratio compared to FAST/HIGH is about 1.5.

Fine.

Yalac - Comparisons

Reply #344 –
Code: [Select]
(Compilation -- hard rock) 69:24   19 files   734,536,700 bytes
===============================================================
name/params		Ratio	EncTime/CPU%	DecTime/CPU%
---------------------	------	------------	------------
TAK 0.12 -p0		70.87%	83.83x / 58%	79.96x / 56% *
TAK 0.13 -p0		70.90%	79.57x / 56%	79.57x / 53% *
MAC 4.01 beta2 -c1000	71.48%	48.92x / 73%	52.10x / 88%
WavPack 4.4a2 -f	73.29%	63.98x / 55%	72.52x / 53%
FLAC 1.1.3b1 --fast	77.58%	52.64x / 43%	68.46x / 45%
OFR 4.520 --mode fast	70.73%	22.95x / 82%	35.13x / 98%
---------------------	------	-----------	-----------
TAK 0.12 -p1		70.36%	63.72x / 60%	77.25x / 57% *
TAK 0.13 -p1		70.39%	61.17x / 59%	78.18x / 54% *
MAC 4.01 beta2 -c2000	70.51%	46.93x / 94%	42.95x / 94%
WavPack 4.4a2 (default)	72.12%	57.17x / 60%	70.41x / 61%
FLAC 1.1.3b1 (default)	72.03%	45.79x / 68%	69.60x / 50%
OFR 4.520 (default)	69.78%	17.09x / 87%	25.08x / 99%
MP4ALS RM17 (default)	71.40%	27.02x / 85%	47.27x / 54%
LA 0.4 normal		68.66%	 6.16x / 99%	 7.60x / 99%
---------------------	------	-----------	-----------
TAK 0.12 -p2		70.17%	51.67x / 66%	78.66x / 58% *
TAK 0.13 -p2		70.14%	51.87x / 77%	80.59x / 57% *
MAC 4.01 beta2 -c3000	69.74%	40.17x / 93%	38.58x / 95%
WavPack 4.4a2 -h	71.21%	46.44x / 64%	64.56x / 71%
OFR 4.520 --high	69.46%	11.72x / 91%	16.59x / 99%
MP4ALS RM17 -7		69.66%	 1.30x / 99%	15.86x / 90%
LA 0.4 high		68.59%	 4.56x / 99%	 5.40x / 99%
---------------------	------	-----------	-----------
TAK 0.12 -p3		70.04%	44.59x / 81%	74.92x / 57% *
TAK 0.13 -p3		69.77%	38.39x / 91%	75.01x / 66% *
MAC 4.01 beta2 -c4000	69.29%	23.08x / 98%	23.17x / 98%
WavPack 4.4a2 -h -x	70.99%	27.42x / 82%	57.55x / 63%
FLAC 1.1.3b1 --best	71.58%	11.72x / 99%	65.01x / 47%
OFR 4.520 --best	69.12%	 4.87x / 96%	 6.60x / 99%
TAK 0.12 -p4		69.75%	31.40x / 75%	68.53x / 62% *
TAK 0.13 -p4		69.70%	22.77x / 89%	67.04x / 60% *


* = Binary comparison OK (TAK tests only)


System = A64 3000+, 512MB, Caviar 80GB, Win2K SP4

Edit: Re-ran 'TAK 0.13 -p3' test and updated results
"Something bothering you, Mister Spock?"

Yalac - Comparisons

Reply #345 –
Nice results.

TAK is beaten for compression by some other codecs, but it has no rival when it comes to size/decode time ratio!

The TURBO and NORMAL presets look very good all-rounders in Soul's comparison.

Yalac - Comparisons

Reply #346 –
Quote from: jido on
Nice results.

TAK is beaten for compression by some other codecs, but it has no rival when it comes to size/decode time ratio!


This is exactly the reason i'm so excited by this codec. I can get compression on par with Monkey's audio AND a decoding speed on par with WavPack. Since i use my lossless as a transcoding source as well, this is very important. Can't wait for it to be released!

Yalac - Comparisons

Reply #347 –
Bug report 1 for V0.13

Destroid has sent me a mail with a bug report. Decoding of a big file (about 700 MB) gave the error "Meta data damaged". Nevertheless the audio data itself could be decoded without any errors.

It took some time to locate the error. There is a bug in my file io class (which i have been using for years without any trouble). It shows up when the class performs buffered reading and then has to jump to a file position outside of the buffer. This is likely to happen when reading the seek table and a file is longer than about 7 to 10 minutes.

Probably i will wait with a fix until the next version, because i anyhow want to replace my object oriented file io class with some function oriented code which would be easier to translate to standard C.

Thanks for the bug report!

  Thomas
 

Yalac - Comparisons

Reply #349 –
Thomas! It's been almost a month since the last update. Any news on 0.14? Are you still making progress?

I don't mean to rush you, but I am really anxious to try out TAK. Watching the development has been very exciting; hope things are going OK.

Cheers,
quas