I'm a senior now. I'll graduate next fall. I was thinking that I would like to take on a project over the summer and hopefully get some credits for it from the university. Anyway, I was thinking about writing a simple lossy audio compression codec. That is contingent on the actual process being somewhat like how I have it in my head right now. If it is overly complicated I fear that I will not be able to pull it off in three months.

Anyway, is this basicly how this stuff works? You take a frame of a wave and run a Fourier transform to decompose it into it's overtones. Then you remove as many as you can by using that frequency vs amplitude chart, or masking, or other things. What your left with is a simpler representation that takes less bits to represent? This is just a guess. If there's any good information out there on how this is generally done, I would love to take a look at it. Thanks.

Could you make us a new and better musepack? http://www.personal.uni-jena.de/~pfk/mpp/a...er_english.html

I must say, if torok manages to create a new and better musepack in three months, without previous codec development experience, I will be very impressed.

Any developer wanting to contribute to MPC is welcome .....

Would it be a good idea to make clear the tasks needed once you get the sources available?I know you did a list before, but it might be useful to start it afresh.

sean

Got off track rather quickly there.

Back to the topic:

There are several variables at play. First and foremost is what your university would be willing to give you credit for. Second, whether you want your work to be used, or you are happy with the credit and the experience. Third, how much time you can dedicate and what experience you bring.

Writing a codec from scratch, including container, compression, front-end, etc. will take up a summer, and you will end up with Yet Another Useless Rudimentary Codec. But the project will be well-defined and self-contained, so the university will be happy to give credit for it.

What this community will beg you to do instead is to take an existing open-source codec and improve it. This will have a greater emphasis on code reading and teamwork, and will demand deeper expertise in a narrower exercise. It will be harder to define what exactly you are up to up front for the university. But it will look better on a resume and the results will be actually used.

There is a wide variety of tasks, from hard core psychoacoustic tuning to UI/plugin writing. The two sweetheart codecs in the community that could use work are MPC and Vorbis. Ask around.

If your interested in quality tuning, my inclination is that Vorbis would probably be a fair bit easier, but you probably already know that.

I was just thinking about doing a throwaway program, but maybe I'll take a look at some Vorbis source. I'm just afraid the learning curve would be too steep unless I can get my hands on a lot of literature.

Faac would probably be even easier

I am also afraid that doing a project for an audio encoder could be too big of a task for one summer, especially if you are starting from zero. Any modern audio compression format today is using psychoacoustical methods to determine what information in the original audio can be dropped.

Understanding the characteristics of the human ear, so you would be able to develop and improve such a 'psy-model' , would take the complete summer alone IMO.

On the other hand, your uni will certainly require that your project will match a certain level of complexity, to show that you are able to understand a technical task, and can develop means to complete it, and fully on your own.

Here a list of things i liked to have done for matroska and MPC :

1. Develop a commonly usable, comprehensive but not overly complicated codec API for both audio, video and subtitles codecs. There had been some attempts made in this direction, like UCI and now recently Media-API. The FFMPEG, gstreamer and mplayer ( G2 ) projects could be a nice source of inspiration for that.
The API had to be
- developed
- documented
- example code/library ( x-platform ) been made for it
- example implementation into certain codecs ( XviD, Lame, FFAC )
This project could have a huge and positive impact on the complete opensource audio/video development scene, as codec developers could use a standardized API for their projects, making implementation of specific codec support into a variety of different projects much much easier.

2. Write a x-platform media player based on gstreamer, the opensource media framework from GNOME/Linux, including the work for porting it to Win32 and MaxOSX. A huge, but very interesting task, especially when thinking about finding the right common platform for the GUI ( wxwindows will work on win32 and Linux, but MacOSX ? ) to cover all these OSes.
Gstreamer is like the Linux equivalent for DirectShow. We started porting it to Windows already, so you wouldnt need to start from scratch. Its quite powerful and still compact enough to be shipped with an application like a media player or media editor, so this ground work could be the basis for a complete new era, rendering both Quicktime ( MacOSX ) and DirectShow ( Windows ) as OS specific solutions only pointless.

Any interesting task for you here ?

I agree, both MPC and Vorbis are pretty pretty well tuned, whereas FAAC doesn't get much attention.

One approach is to do something simple (and crap), find a way to show at least a little original thought, enjoy the project, finish on time, and get some credit.

The opposite approach is to take something really advanced, and try to improve it in three months. If university grades depend on it (and if you haven't even thought of doing this as a hobby before!), then this sounds like academic suicide to me.

A middle-line approach might be to find someone else's project (which was 3 months, and the result was crap) and build upon it. So you're not starting from scratch, you can use all their background research, and you can make a useful, genuine improvement.

I suggest this because in my experience, 3 months (part time) is just long enough to realise what you should have done on a project, but not actually do it. If you can take advantage of someone else going through this, you might get somewhere.

Remember as well as designing it, you'll have to test it as well, which means carrying out some limited listening tests. All in 3 months!

Cheers,
David.

An interesting idea may be to try to apply other peoples work in a different way. Frank Klemm, the developer of MPC, has commented that it should be possible to make his psy model into a pluggable design to be used with different codecs. It seems to be the general consensus that his psy model is the best, or close to it. So, if you were able to make his psy model into a general pluggable system that could be used with other codecs, that may work. This would offer lots of opportunities to test theories on how transportable psy models are for different audio encoding methods.

right. perhaps, maybe, using the mpc psy-model and integrating into an mp3 codec!

sounds familiar?

I must say, this thread has really blown my mind.
Just to realize the amount of work a codec needs to be able to squeeze a piece of music to a fraction of its original size is mind-boggling!

I fix broken bones for a living and I think this is more complicated!

Good luck on your project, although I do agree you could try to improve an existing codec. FAAC? LAME? I think those would look better to a University, as both are the most well-known of formats.