Greetings.

Just finished porting Justin Ruggles' FLAKE encoder to C#.

I believe this to be the first pure managed FLAC encoder, which should be able to run on any CPU/system with .NET (e.g windows xp/vista/7, and linux with Mono).

You can download it here: Click to view attachmentPrevious versions: Click to view attachmentClick to view attachment
Source code can be found here: http://cuetoolsnet.svn.sourceforge.net/vie...s.Codecs.FLAKE/

As you can see, it turned out to be very compact.
I also hope that you'll find it pretty fast for a .NET, and i also hope that it has a very competitive compression ratio.
Flake itself provides a very good compression ratio, but my version has quite a few new optimizations.

Please, test it and post here the comparisons for speed/compression ratios with other FLAC encoders. Please note, that compression levels are tuned differently here from libFLAC or Flake. CUETools.Flake -5 should be roughly equivalent to flac -8. So to compare against flac -5 you'll probably want to test CUETools.Flake -3. Levels above 8 produce non-subset files (e.g. not all hardware players will read them).

The default compression level is 7, which produces files noticeably smaller than flac -8 while being fast enough.

hey, that's cool. wrapping a gui around this would be no time then. the results:

c# encoder:
time: 2:31
size: 566 MB

flake 0.11:
time: 1:09
size: 575 MB

flac 1.2.1:
time: 1:20
size: 573 MB

all done with -5

however, the results can be a bit bogus, coz i'm doing some cvs checkout in the background

i would say it's not bad, especially for an initial release. thanks for your work!

what version of .net is this written in anyway?

2.0, but i'm pretty sure it could be compiled with 1.0 or compact framework.

Please note, that compression levels are tuned differently here from libFLAC or Flake. CUETools.Flake -5 should be roughly equivalent to flac -7 or 8, i guess. So to compare agains flac -5 you'll probably want to test CUETools.Flake -4 or 3

-4:
time: 2:16
size: 566 MB

-3:
time: 1:36
size: 574 MB

-3 is comparable in compression with flac -5, and is just ~15% slower, so i'd say it's really not bad

I like speed over compression & I think that I understand the purpose of flake, but flake needs a serious comparison like KTF's one in order for the average people to understand its use. Judging from flake benchmark, you lose ~1% compression & some decompression speed for a huge bost in compression speed ... the compression speed gain is bigger than the decompession speed loss. So if I would sum up, overall (decompression+compression) flake is slightly faster than flac for a 1% compression loss at the same setting ... but you lose the "safety" of using official flac. Right ?

I like the idea, but honestly, I may be paranoid, but I would never use it unless other people also start to use it. I think others think like me, so no-one except audio enthousiast will use it. It's sad but I think Flake being a "fork" it's caught in the vicious circle of FUD & like lossywav vs pure lossy, flake will have hard time struggling with flac as the average user will not understand the benefit. IMHO, there is more important features/fixes to code for cuetools than flake. I was thinking that you were on vacation in Canada, & you were coding for flake, what a disapointment

As an example I was using flac -6 before using cuetools, after starting using cuetools I searched for a setting with faster decoding speed & that's why I started using -4. I never even a second imagined that I could seriously use flake, but I thought of sacrificing 3% compression & using -1 if -4 is still not fast enough. It's only an example but it shows what flake is in the mind of people, an experimental codec for a niche market, despite all its quality. Let's hope it will change, but I doubt it.

I agree that Flake is an experimental codec. Whatever market it has is not very important to me. My reason for creating it in the first place was to better understand FLAC, and lossless audio in general. I'm glad to see that others have taken the code and used it in ways that they find helpful. Since only a little of my time is dedicated to improving Flake, the fact that Gregory has improved it in his C# port is wonderful.

this is cool, I would just suggest running it through the flac test suite before each release, to make sure the port is ok. encoders have to be held to a higher standard than decoders because people usually delete the original afterwards.

the quickest way is to build flac with visual studio or gcc and substitute flac.exe with a command-line wrapper for your encoder.

Thanks, will do that. This encoder also has a verify mode, like libFLAC, when it decompresses each compressed frame and compares with original. This mode will be recommended for initial releases. It is activated by --verify switch.

hah yeah i was checking out your code on sourceforge or wherever you have it and i noticed an awful lot of the recent revisions had been all related to FLAKE.. i figured something was up

kind of made me want to get back into programming looking at it, to be honest. used to be a hobby of mine, but i lost it over the years.. and I was kind of getting away from it when .NET framework started coming out... I remember a couple of the System namespaces, etc provide a lot of the base functions for the programs, but by no means was I a pro at it, just experimental. I had always been a C/C++ fan, so the idea of C# and .NET framework seemed interesting to me.

Ah yes... I remember.. I was an ASM programmer for 2-3 years there, and the last thing I wanted to do was go home and code. What is a good resource for getting a good overall idea of the .NET framework? I suppose MSDN would be a good start to just look up the different namespaces and what all functionality each provided. I know and understand the code part of it (as far as like the part that is based on C/C++ coding).. but I need to find something to help tie that in with .NET.


Couple of questions.. sorry to really get off the 'main' topic, but I have a couple of questions...

What are the differences between the different major versions of .NET framework... 1, 2, 3, 3.5, etc. I'm assuming added functionality, but were there any major changes or additions, etc that changed the way the framework was used, or what it could do?

I just need to get to google and look it up.. but I just wanted to say that I did look at certain parts of your code for CUETools, and it gave me a little bit of motivation/interest to maybe get back into it as a hobby --- so thanks for that!

Btw, I heard that the compiler for .NET apps basically converts all the languages into some intermediary code, then compiles that... essentially suggesting that no one coding language was necessarily 'better' in terms of the end compile's speed/memory footprint/functionality.. meaning that regardless if you create the same program in visual basic/c#/c++, they should all result in the same optimized code in the end, since a lot of it is all sharing the same codebase via .NET. is this true? (i do understand that it is up to the programmer to make their code efficient, optimized, etc and that can definitely have a huge impact on performance).. but essentially, if the same coder wrote the same program the same way in each of the languages, the end compile is going to be about the same? i know that ASM programmers used to brag how compact, efficient, and powerful their code was and laugh at visual basic programmers, "drawing" their programs, writing simplistic code with all of these DLL/OCX dependencies and it basically being "kiddie coding".... but it seems technology like .NET has kind of leveled the playing field out a bit, considering each of these languages are relying on the same set of "dependencies", etc. I mean, to me... I have no bias really, because I have written programs in visual basic before, and i coded ASM programs for a living too... so really, i don't see something like visual basic or visual c# to be "coding for beginners". it's code that is easier to understand, write, and manage.. is that a sin? depends who you ask i guess...

IMO, i feel that visual C++ can sometimes get a little more complicated with stuff like dereferencing of pointers and this type of thing, and of course visual basic is at times a little too... basic, as it is a bit copy and paste this, drag this here... then do something like whatever.Color = blue, it's almost like programming in english -- it seems to me that C# is a nice compromise between the two languages... the power of c++ with the simplicity of visual basic -- and i believe that was probably the intended result.

anyways, enough of the ramble.. got to get back to work.

Wikipedia has a nice article where the changes are described. http://en.wikipedia.org/wiki/.NET_Framework



Yes, that's the theory (never tested it myself if the CIL, that's the name of the semi-compiled stuff, genereated by C# is identical to the one made by VB .NET given the fact that there are things you can do with one language but not with the other, though).



You mean vbBlue in VB6 and earlier or System.Drawing.Color.Blue in .NET.