Purely managed .NET MP3 encoder?, Finding a 100% managed MP3 encoder with no references to anything out Options

[josh comley]

Does anyone know if anyone has implemented a purely managed .NET MP3 encoder?

I'm not talking about using the lame.dll; I've already implemented that solution. I mean with no references to anything outside of .NET. It is possible, but I'm not sure if anyone has actually bothered yet and I've had no luck finding a solution myself!

Ideally a port of Lame's algorithm to completely managed code would be nice, but I'm doubting that exists. Someone must have written a very basic (it doesn't need to be super high quality) .NET based MP3 encoder!

I'm hoping I'm not going to have to spend the next six months learning how to encode MP3s manually!

Thanks peeps,
Josh

[Jebus]

Does anyone know if anyone has implemented a purely managed .NET MP3 encoder?

I'm not talking about using the lame.dll; I've already implemented that solution. I mean with no references to anything outside of .NET. It is possible, but I'm not sure if anyone has actually bothered yet and I've had no luck finding a solution myself!

Ideally a port of Lame's algorithm to completely managed code would be nice, but I'm doubting that exists. Someone must have written a very basic (it doesn't need to be super high quality) .NET based MP3 encoder!

I'm hoping I'm not going to have to spend the next six months learning how to encode MP3s manually!

Thanks peeps,
Josh

Large parts of Lame are written in x86 assembly, so (compared to a managed wrapper like you have now) what are you hoping to accomplish? It would be a lot of work for something that is simply a lot slower.

[chelgrian]

Large parts of Lame are written in x86 assembly, so (compared to a managed wrapper like you have now) what are you hoping to accomplish? It would be a lot of work for something that is simply a lot slower.

You can fallback onto C code paths I think, I'm not sure if there are predefines to remove the assembly paths completely from the compile.

The OP could then compile it using MSVC++ and output CLR bytecode rather than machine code and wrap the interface code in a C++ class which can be exported as a managed object. The only possible reason for doing this is if the OP wants the resulting object to be portable to a version of the .NET Framework running on a non x86 platform or under a non Windows operating system.

However given lame is (mostly) under the LGPL either it would need to be distributed as a shared library or as a separate executable if the OPs application is closed source or the application would need to be licensed under an LGPL compatible license.

Given the result would be dog slow you do have to wonder what the point is, what is the OPs actual objective?

[jetpower]

I'm not really sure if this is of any help because I'm a noob at this but lame sources contain Visual Studio project files and they have compiler profiles, also without nasm assembly. Lame complies without using nasm and was about 4-5 times slower than the Mar 12 compile from rarewares.org on my core2.

This post has been edited by jetpower: Mar 26 2008, 00:23

[lvqcl]

I'm not really sure if this is of any help because I'm a noob at this but lame sources contain Visual Studio project files and they have compiler profiles, also without nasm assembly. Lame complies without using nasm and was about 4-5 times slower than the Mar 12 compile from rarewares.org on my core2.

Try 'the Mar 12 compile from rarewares' with "--noasm mmx --noasm sse --noasm 3dnow" options.
It is only some percent slower, not 4-5 times. I think there's something wrong with your project settings.