FLACOUT from Ken Silverman

Topic: FLACOUT from Ken Silverman (Read 9115 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.

FLACOUT from Ken Silverman

2014-06-25 12:23:31

Hello,

Available here (Thanks to nikkho).

AiZ

FLACOUT from Ken Silverman

Reply #1 – 2014-06-25 14:03:18

I was curious enough to give it a try. I like my files being subset compatible so I ran it with /sub parameter. After 35 minutes of processing of a test file the program crashed. My test file was a 33.9 MB CD sourced regular 16 bit stereo FLAC.

FLACOUT from Ken Silverman

Reply #2 – 2014-06-25 18:11:33

Darn, that thing is slow.

FLACOUT from Ken Silverman

Reply #3 – 2014-06-25 18:14:43

Hahaha, why does this exist? It's been an hour and my file is at 11%.
Is it brute forcing the blocks and modeling using FLAC's super-secret setting?

I'm assuming the decode speed is going to be slower also.

-From the verbose output it's brute forcing parameters for "mode", "order" (max lpc order), and "lpcbits" (qlp coeff precision).

FLACOUT from Ken Silverman

Reply #4 – 2014-06-25 18:47:13

It says it's using variable blocksize, which is indeed an in-subset possibility that the reference encoder does not use. It is really tiny, only 20kB, that's pretty impressive.

edit: Oh, and for anyone who's going to try out, it's two-pass, so don't be fooled. It is really slow Knowning FLAC, decoding will probably still be really fast. Still, if the promise of 3 to 5% better than the reference encoder is kept, that would be really impressive. It would beat TAK on pure compression. That's too good to be true. Still waiting for the first file to finish encoding though

FLACOUT from Ken Silverman

Reply #5 – 2014-06-25 20:21:22

Tried a metalcore track ("Until It's Gone" by Linkin Park's "The Hunting Party").

Code: [Select]

C:\Users\ferongr>flacout in.flac out.flac
 In:29494475 bytes            in.flac
Out:29240222 bytes            out.flac
Wrote out.flac
Took 4505.755 sec.

The track is 3:53 in length. Flacout speed was 0.05x realtime for a meager 255KB reduction. Decoding speed of the original is ~670x per thread. Decoding speed of the output file is ~618x per thread, quite large a difference.

Edit: Flacout removes ALL metadata. Something of note.

FLACOUT from Ken Silverman

Reply #6 – 2014-06-25 20:38:25

Took 3 hours to reduce the filesize by 511KB. Not very efficient if you ask me...

FLACOUT from Ken Silverman

Reply #7 – 2014-06-26 00:24:47

This was very daunting and labouring.

I picked the shortest track I can think from my personal rips. It was classical music (Douglas Pipes - "Trick'R'Treat (2007) Original Motion Picture Soundtrack": Track 2 "Meet Charlie" (0:45 seconds))

It took 1027.011 sec (17+ min) and only reduced file size marginally (63183 byte difference, see pic below).
(I should have tried a more heavier track instead of simple classical orchestration).
I do notice, Ferongr mentioned, that all the metadata was stripped.

MediaInfo reveals nothing about the writing library.
Q-Dir (quad-directory viewer replacement instead of Windows Explorer) doesn't read any data at all, except for filesize.
Length and bitrate don't appear for the FLACOUT encode.

I have an Intel Core-i5 2320@3.00GHz, 4 logical cores.
It only consumed, at most, ~~40%~~ 20-30-ish% (forgot I had other tasks running in the background; not that it ever impacted overall performance on anything at any single time) CPU usage and a single thread.
I also have 2 SSD's where I kep the original FLAC file and the encoded FLAC file.

Most of my music collection consists of motion picture scores (classical), so I don't see a huge impact on saving space with this.
The reduced file size is no real benefit when a much more apt solution would be to get another external to backup my backups.
I can't see myself going through the trouble of tagging all over again.
I don't like automatic tagging as it relies heavily on what other people submit, and I rarely like what anyone else does.

I just started looking into alternatives for FLAC encodes, and have yet to try FLACCL.

I can safely cross FLACOUT off my list and move on.

Thanks for the share and interest, but alas, it is short lived.

FLACOUT from Ken Silverman

Reply #8 – 2014-06-26 00:42:00

Here Avira reports it as "TR/Crypt.XPACK.Gen" Virus. Maybe a false positive. I wanted to test against flacCL. It can create smaller files already with default -8 without using something non subset compatible or variable bitrate. Anyone tried this? flacCL works nicely with integrated HD Intel graphics if you didn't know.

FLACOUT from Ken Silverman

Reply #9 – 2014-06-26 01:02:19

^^^ Probably because the file is (i think) a compressed binary.

Not too surprising that the author would pack the binary given that he writes utilities for repacking compressed files

FLACOUT from Ken Silverman

Reply #10 – 2014-06-26 02:15:40

Never understood the point of packing executables. To waste memory when executing?

FLACOUT from Ken Silverman

Reply #11 – 2014-06-26 03:35:17

I did run it and my PC didn't explode so most likely no virus.

It took 1343 sec. for encoding a 4:28 min song with /sub and a fixed blocksize of 4096 running my Intel Ivy @4400.
It stopped working with solely /sub 3 times exactly at the same 98.1% with this same file.
I used /sub and a blocksize of 4096 to comparte it directly to flac and flacCL
The result is a bit disappointing. No more testing planned.

flacCL -8        23.350.986 Bytes
flac 1.30 -8      23.386.104 Bytes
flacout /sub /v4096   23.358.609 Bytes

FLACOUT from Ken Silverman

Reply #12 – 2014-06-26 09:01:36

Quote from: xnor on 2014-06-26 02:15:40

Never understood the point of packing executables. To waste memory when executing?

With authors like Ken Silverman and Ian Luck, it's likely to protect their secrets slightly better than no compression at all.

With the demoscene, it's always about compressing the most into a tiny executable, since they have categories for intros by KB size. Frequently, the compression tools they use, like Beropacker and .kkrunchy, set off at least a dozen AV scanners with every executable they spit out, and often take 5-10 seconds to load on any system with a heuristics based real time scanner installed.

FLACOUT from Ken Silverman

Reply #13 – 2014-06-26 14:22:03

Quote from: Wombat on 2014-06-26 03:35:17

flacout /sub /v4096 23.358.609 Bytes

Sorry it was late here. Correctly it must be: flacout /sub /b4096

FLACOUT from Ken Silverman

Reply #14 – 2014-06-26 15:39:37

I've been wondering whether using a variable blocksize could lead to smaller FLAC files, but it seems that this implementation is no proof. Flake didn't too well with variable blocksizes either, but according to Justin (the Flake developer), the algorithm wasn't really tuned nor smart. Maybe a possibility for FLACCL to look into?

FLACOUT from Ken Silverman

Reply #15 – 2014-06-26 20:48:20

When i remember right it was spec of flac but Mr. Coalson himself found not enough avdantage in using it. It most likely could have broken playback on many devices and players when pushed into a release.

Notice