Open source C# namespace to convert many audio formats

[gilad]

Hi, I have just released the initial beta of a C# project called
'aumplib'. aumplib is a C# namespace which is made up of a set of
classes that interface several prominent open source audio conversion
projects via DLL and P/Invoke: LAME (MP3 encoding), libsndfile (non-MP3
audio conversion), and libmad (MP3 decoding; through madlldlib).
Essentially, aumplib provides an OO wrapper to these libraries.

I am interested in any comments anyone would like to make on the code.
I've been programming C# for less than a year (programming in other
languages longer), and would like to ensure that I haven't made some
faux pas in regard to the use of C#. Please be constructive if you want
to comment.

You can download the source at:

http://www.arbingersys.com/dnlds/aumplib-1.0b1.zip

(There's too many source files to try and paste into this message.) If
you wish to leave your comments or questions in my development forum you
can:

http://www.arbingersys.com/forums/viewforum.php?f=3

A short outline of how the namespace is arranged is below.

namespace aumplib {

- class aumpifc
[Primary interface to other classes]

- class lame_wrap
[Interfaces with LAME DLL, lame_enc.dll, for MP3 encoding]

- class lame_write
[Uses lame_wrap and overrides BinaryWriter for easier usage in C#]

- class libsndf_wrap
[Interfaces with libsndfile.dll to convert between many non-MP3 audio
formats]

- class madlldlib_wrap
[Interfaces to madlldlib, a DLL for decoding MP3]

- class madnpsrv_wrap
[Uses named pipes to communicate to madlldlib for MP3 decoding]

}

Thanks, James

 

[Drebin]

I didn't see anything that popped out, but as some constructive criticism,
your "interface" to your developer users is sort of confusing and
intimidating.

On the one hand, you don't want to have this Fisher-Price "My First
Programming Object", but on the other hand, there is nothing wrong with
making things nice and simple. A developer has other things to do, your
object should HELP him by being easy to use and intuitive.

As a general rule (at least nowadays and in .NET) - method arguments should
have regular names, and no prefixes. In other words:

lame_write(Stream ostrm, string ifilnm)

should be prettied up to be (ALWAYS use verb-noun, like GetUser(),
AddCompany(), DeleteStream(), etc):

WriteLame(Stream OutputStream, string FullPathAndFilename)

Point is, when you have all your functionality, you should spend some time
to make the developer interface as clean and simple as possible. They have
better things to do than to try to figure out what you were thinking or
trying to make sense of these eye-crossing bunch of letters - like "ostrm"
and "ifilnm"!!

Just my $.02 - no offense!!

 

[Dennis Myrén]

I agree with you, except i disagree with using PascalCasing in parameter
names:
WriteLame(Stream OutputStream, string FullPathAndFilename)
I would rather use camelCasing:
WriteLame(Stream outputStream, string filename)

Well, that is my opinion anyway.

--
Regards,
Dennis JD Myrén
Oslo Kodebureau

I didn't see anything that popped out, but as some constructive criticism,
your "interface" to your developer users is sort of confusing and
intimidating.

On the one hand, you don't want to have this Fisher-Price "My First
Programming Object", but on the other hand, there is nothing wrong with
making things nice and simple. A developer has other things to do, your
object should HELP him by being easy to use and intuitive.

As a general rule (at least nowadays and in .NET) - method arguments
should have regular names, and no prefixes. In other words:

lame_write(Stream ostrm, string ifilnm)

should be prettied up to be (ALWAYS use verb-noun, like GetUser(),
AddCompany(), DeleteStream(), etc):

WriteLame(Stream OutputStream, string FullPathAndFilename)

Point is, when you have all your functionality, you should spend some time
to make the developer interface as clean and simple as possible. They have
better things to do than to try to figure out what you were thinking or
trying to make sense of these eye-crossing bunch of letters - like "ostrm"
and "ifilnm"!!

Just my $.02 - no offense!!

Hi, I have just released the initial beta of a C# project called
'aumplib'. aumplib is a C# namespace which is made up of a set of classes
that interface several prominent open source audio conversion projects
via DLL and P/Invoke: LAME (MP3 encoding), libsndfile (non-MP3 audio
conversion), and libmad (MP3 decoding; through madlldlib). Essentially,
aumplib provides an OO wrapper to these libraries.

I am interested in any comments anyone would like to make on the code.
I've been programming C# for less than a year (programming in other
languages longer), and would like to ensure that I haven't made some faux
pas in regard to the use of C#. Please be constructive if you want to
comment.

You can download the source at:

http://www.arbingersys.com/dnlds/aumplib-1.0b1.zip

(There's too many source files to try and paste into this message.) If
you wish to leave your comments or questions in my development forum you
can:

http://www.arbingersys.com/forums/viewforum.php?f=3

A short outline of how the namespace is arranged is below.

namespace aumplib {

- class aumpifc
[Primary interface to other classes]

- class lame_wrap
[Interfaces with LAME DLL, lame_enc.dll, for MP3 encoding]

- class lame_write
[Uses lame_wrap and overrides BinaryWriter for easier usage in C#]

- class libsndf_wrap
[Interfaces with libsndfile.dll to convert between many non-MP3 audio
formats]

- class madlldlib_wrap
[Interfaces to madlldlib, a DLL for decoding MP3]

- class madnpsrv_wrap
[Uses named pipes to communicate to madlldlib for MP3 decoding]

}

Thanks, James

 

[Daniel O'Connell [C# MVP]]

I agree with you, except i disagree with using PascalCasing in parameter
names:
WriteLame(Stream OutputStream, string FullPathAndFilename)
I would rather use camelCasing:
WriteLame(Stream outputStream, string filename)

Well, that is my opinion anyway.

Your's, the MSDN naming conventions, and *many* others. Camel casing
parameters is probably as close to standard as you are going to get.

 

[Drebin]

Yikes! It was just an opinion - uptight much??

For the record though, the reason I don't like camel casing is because it
makes it look like the first "word" is the data type. In other words, with
hungarian, you have something like strFilename, which is clear. If I saw
fileName - I would be confused, because fileConfig would make me think that
that is a pointer to a File object for the config file.

So - just my $.02 because I find camel casing confusing..

 

[gilad]

Your's, the MSDN naming conventions, and *many* others. Camel casing
parameters is probably as close to standard as you are going to get.

Yeah, I knew I was breaking the MSDN's convention in using the all
lowercase, underscore delimited style. I did this consciously, however.
The reason is because I grew up on Perl, and that community's style
preference tends to be this way. I submitted a CPAN module and found
(and got used to): classes start uppercase, methods are lowercase and
underscored. I am not using this style entirely in aumplib, but I have
definitely been influenced by it. I prefer not having to use my Shift
key all that much. Maybe I won't get away with it in C#, I don't know.
The style preference seems fairly entrenched (much like Perl's is on the
opposite spectrum). We'll see.

As for short variable names, I wasn't trying to obfuscate, I was just
conserving. I'll check the code and see if I can be a little more
enlightening in my variable names. I appreciate the comments (I'm glad
I'm hearing about syntax rather than construct errors).

 

[Daniel O'Connell [C# MVP]]

Yeah, I knew I was breaking the MSDN's convention in using the all
lowercase, underscore delimited style. I did this consciously, however.
The reason is because I grew up on Perl, and that community's style
preference tends to be this way. I submitted a CPAN module and found (and
got used to): classes start uppercase, methods are lowercase and
underscored. I am not using this style entirely in aumplib, but I have
definitely been influenced by it. I prefer not having to use my Shift key
all that much. Maybe I won't get away with it in C#, I don't know. The
style preference seems fairly entrenched (much like Perl's is on the
opposite spectrum). We'll see.

I will say you probably will not get away with it. Personally I would *not*
use your library simply because its naming conventions are so at odds with
those I am used to. It makes the library seem written by someone who does'nt
know what he's doing.

While I understand you are used to perl's naming conventions, those *are*
perl's naming conventions and are not a very good choice in a platform that
doesn't use them.

Anyway, while I can see you're worried about shift key, a good number of
characters you have to use commonly in C# code require shift, inclufing _.
Whats the difference in typing

something_else and somethingElse? Same number of shift presses, after all.

You classes should be clearer too, . Avoid using abbreviations when you
can avoid it.

 

[Drebin]

I guess the general gist of what people are saying is that "when in Rome, do
as the Romans do".. when you are writing perl, use that style, when you're
using C#, use a Microsoft-ish style..

 

[Daniel O'Connell [C# MVP]]

I guess the general gist of what people are saying is that "when in Rome,
do as the Romans do".. when you are writing perl, use that style, when
you're using C#, use a Microsoft-ish style..

Certainly a good way to put it. Doing anything else will probably just
confuse people. I imagine perl people would be aggervated and make mistakes
with code written in .NET style just as I am with code written in perl's
style(of course, just writing in perl aggervates and confuses me, .

Daniel O'Connell [C# MVP] wrote:


I agree with you, except i disagree with using PascalCasing in
parameter names:
WriteLame(Stream OutputStream, string FullPathAndFilename)
I would rather use camelCasing:
WriteLame(Stream outputStream, string filename)

Well, that is my opinion anyway.



Your's, the MSDN naming conventions, and *many* others. Camel casing
parameters is probably as close to standard as you are going to get.



Yeah, I knew I was breaking the MSDN's convention in using the all
lowercase, underscore delimited style. I did this consciously, however.
The reason is because I grew up on Perl, and that community's style
preference tends to be this way. I submitted a CPAN module and found
(and got used to): classes start uppercase, methods are lowercase and
underscored. I am not using this style entirely in aumplib, but I have
definitely been influenced by it. I prefer not having to use my Shift
key all that much. Maybe I won't get away with it in C#, I don't know.
The style preference seems fairly entrenched (much like Perl's is on the
opposite spectrum). We'll see.

I will say you probably will not get away with it. Personally I would
*not* use your library simply because its naming conventions are so at
odds with those I am used to. It makes the library seem written by
someone who does'nt know what he's doing.

While I understand you are used to perl's naming conventions, those *are*
perl's naming conventions and are not a very good choice in a platform
that doesn't use them.

Anyway, while I can see you're worried about shift key, a good number of
characters you have to use commonly in C# code require shift, inclufing
_. Whats the difference in typing

something_else and somethingElse? Same number of shift presses, after
all.

You classes should be clearer too, . Avoid using abbreviations when you
can avoid it.

As for short variable names, I wasn't trying to obfuscate, I was just
conserving. I'll check the code and see if I can be a little more
enlightening in my variable names. I appreciate the comments (I'm glad
I'm hearing about syntax rather than construct errors).

 

[Jon Skeet [C# MVP]]

I guess the general gist of what people are saying is that "when in
Rome, do as the Romans do".. when you are writing perl, use that
style, when you're using C#, use a Microsoft-ish style..

Exactly right. Personally I find this also helps me to think in C#
idioms rather than the idioms of whatever language I'd be tempted to
use the naming conventions of. Trying to use one language as if it's
another is never a good idea.

 

[Guest]

I will say you probably will not get away with it. Personally I would *not*
use your library simply because its naming conventions are so at odds with
those I am used to. It makes the library seem written by someone who does'nt
know what he's doing.

But if you were a programmer who seriously needed the functionality of the
library, would you still balk at the style? It doesn't seem likely. You'd
probably shrug your shoulders and shake your head, and use it. And as for it
having the appearance of being "written by someone who does'nt know what
he's doing", isn't the actual code logic going to tell this rather than the
style? If I'm doing everything correctly as far as interfacing the DLLs,
construction of objects, etc, and yet decide to use a slightly different
naming convention (because it is style we're talking about here isn't it?),
doesn't that say whether or not I "know what I'm doing"? Breaking a style
convention could also be considered being a 'rebel'.

While I understand you are used to perl's naming conventions, those *are*
perl's naming conventions and are not a very good choice in a platform that
doesn't use them.

Like I said, I was influenced by this style convention, not using it
explicitly. And I have alternated the Perl style in my own projects when it
suited me. Only when I have submitted to a repository like CPAN have I
conformed entirely. (Largely because the hue and cry that rang out from there
when I didn't.)

Anyway, while I can see you're worried about shift key, a good number of
characters you have to use commonly in C# code require shift, inclufing _.
Whats the difference in typing

something_else and somethingElse? Same number of shift presses, after all.

You got me there. I do use underscores. But I only do it where I need to
separate words for clarity (what I consider clarity anyway), so a lot of my
variables were pretty short and without the underscore (which seems to draw a
lot of criticism too; see below). The convention of C# uses long names most
times, and at least have one shift operation for every named thing.

You classes should be clearer too, . Avoid using abbreviations when you
can avoid it.

Sigh. I like abbreviations. So short, so succinct... Okay, thanks for the
comments.

 

[Guest]

Hi, I have just released the initial beta of a C# project called
'aumplib'...

Thanks everyone for the feedback. I didn't really want to start an
impassioned debate about the code's naming convention. I guess this was
good--I've found how important the style is to people. I hadn't really taken
much thought about it, worrying myself mostly with the function of the code.
Fortunately, I consider this a pretty easy fix so it shouldn't be hard to
conform. (Then maybe I can get some comments about whether the logic of the
code works or not

 

[Drebin]

Gilad,

Please don't take offense, this is really just a lesson-learned (for me
too!) that your "interface" to developers is KEY.. it's equally important
than if your code actually works. Imagine I had DLL's that methods like
gftgd(int x, int n) - having your "interface" be self-describing and
self-documenting turns out to be dare-I-say critical to the success of your
library.

And for the comment of "wouldn't you just shrug it off" - the answer is no.
I've run across many confusing and poorly documented libraries - and at some
point, it's just easier for me to write it myself. I think "I don't want to
rely heavily on this object that doesn't make much sense to me".

You asked for constructive criticism, and you got it - but this has been a
good lesson to everyone. I don't think I've ever thought this much about my
developer interface. So - thanks!!

 

[gilad]

Gilad,

Please don't take offense, this is really just a lesson-learned (for me
too!) that your "interface" to developers is KEY..

None taken. Ultimately, this has helped. I *do* want my library to be
used, and if it takes making aesthetic changes, then that's a small
price to pay.

 

[Daniel O'Connell [C# MVP]]

But if you were a programmer who seriously needed the functionality of the
library, would you still balk at the style? It doesn't seem likely. You'd

Not if it was vital, though I would probably fire off a courtesy email to
the maintainer suggesting he learns proper naming conventions.

However, except in the rare case that a library is the only available that
supports something, I certainly would turn it down in favor of a competitor
that followed conventions.

probably shrug your shoulders and shake your head, and use it. And as for
it
having the appearance of being "written by someone who does'nt know what
he's doing", isn't the actual code logic going to tell this rather than
the
style? If I'm doing everything correctly as far as interfacing the DLLs,
construction of objects, etc, and yet decide to use a slightly different
naming convention (because it is style we're talking about here isn't
it?),
doesn't that say whether or not I "know what I'm doing"? Breaking a style
convention could also be considered being a 'rebel'.

It could be considered a rebellion, but more times than not its simply
"Damn, this guy didn't even bother reading the most basic document". If you
couldn't be bothered to read a styles document, why should I think you took
the time to learn initalization, property, and event patterns?

For the record, I know you have read it, but that is the appearance that is
often taken from code that is not named along with standard style.

Like I said, I was influenced by this style convention, not using it
explicitly. And I have alternated the Perl style in my own projects when
it
suited me. Only when I have submitted to a repository like CPAN have I
conformed entirely. (Largely because the hue and cry that rang out from
there
when I didn't.)

Within your own code, its one thing, but for open source projects
especially, you should look into using standard conventions. 90%+ of users
are going to expect those conventions, meaning some potential contributers
aren't going to contribute due to style alone(if its bad enough, I won't
even bother tryign to dechiper it).

You got me there. I do use underscores. But I only do it where I need to
separate words for clarity (what I consider clarity anyway), so a lot of
my
variables were pretty short and without the underscore (which seems to
draw a
lot of criticism too; see below). The convention of C# uses long names
most
times, and at least have one shift operation for every named thing.

One of the many code clarity guidelines: Use variables that mean something.
LOL. Its just an expectation of good code.

Personally, I use short, but complete variable names. When I'm dealing with
just one array or somesuch, I will use just
int index;
or
int count; (depending). But if the method has a couple of indexers or loops,
I'll do
int charIndex;
int stringIndex;

int charCount;
int stringCount;

or what have you.

Parameters should be fairly clear, but I don't think they should be too
long. XML docs should be the primary source of information about a
parameter, not its name.

Sigh. I like abbreviations. So short, so succinct... Okay, thanks for the
comments.

Yes, very short...but when I don't know what they mean, they become a
difficult issue for me. So using abbreviations for uncommon terms is a bad
idea. You have to remember that your user isn't going to know everything
about audio and they do not want to have to refer back to docments every
time they run across an abbreviation they don't know off hand.