OSDev.org

onlyonemac wrote:

Love4Boobies wrote:Why don't we also cover the IRC protocol? People might want to write IRC clients after implementing NIC drivers and a TCP/IP stack.

If you want to write an IRC client, research the IRC protocol.

Love4Boobies wrote:

And if you want to write an mp3 client research the mp3 protocol. Duh.

I've found several sites that attempt to describe the MP3 format, but they seem to conflict with each other, and the fact that there are several versions and different "layers", I'm finding it fairly difficult to nail down exactly what structure to expect.

I did find a C# project with source code that appears to be able to read MP3 files and send the uncompressed audio to a sound card, so I'm going to be going through that trying to put together my own documentation. Once I'm done, I'll either put it on the wiki, or find another place to put it and link to it, somehow.

A number of moons back, compilers were the topic of the inclusion debate. Considering they can be an integral part of an OS' codebase and it's functioning, it is still in terms of computer science it's very own subject. For something that's highly correlated and lacks an appropriate place elsewhere, it ended being tolerated within the scope.

MP3 is not like a compiler as it is not and will not be an integral design choice in any sane OS design - the same structure would be relevant to formats like OGG or AAC. Secondly, there is already a website referenced with similar functionality where it is an order of magnitude more topical, and would be better there.



@onlyonemac: I don't recall having specific troubles locating documentation on the MIDI (and mod/s3m/xm) format when I tried building my own player for the fun of it - a decade ago. Let it be some sort of consolation that everybody able to use google images will still find a good run down on MIDI on the page behind the first hit today.



[edit] The interleaving MIDI discussion and everything flowing from it was moved to a separate thread

Please consider documenting something on the Wish List ( http://wiki.osdev.org/Wish_List ) instead, which is more targeted at benefiting the general OSdever.

http://web.archive.org/web/200110310722 ... bo/mpg123/
http://web.archive.org/web/20011031072211/http://www.sci.fi/~tobo/mpg123/mpg12304.zip

The URLs above contain information, an executable and source code in a ZIP, for a program called MPG123 (supposedly a DOS port of mpg123 for Linux/UNIX).

The source code is supposed to be confusing to read, but at least this is a good start to have a stand-alone program capable to run in DOS and then port it to another OS.

There's also Winplay 3 for Windows 3.x.
I see how the more I go back in the timeline of popular OSes I find more and more information very easily, as if Google had separated this sort of results by OS epochs (I guess which other OS for old x86 PCs I could search for other than MS-DOS, Windows 3.x, Windows 9x, 8086, 8088, 386 and 486 as base keywords, so I could keep finding portable stuff to port to another OS).

I will test it and compile it in MS-DOS in my 386 and see how it goes.

Rather than porting a port of the Linux version wouldn't it be better to go straight to that version?

https://www.mpg123.de/download.shtml

Another interesting example link, although it seems to work less than the ZIP file in my previous post:
http://www.fareham.org.uk/music/mpg123/index.shtml

Reading the Linux port is easier maybe for some, specially programmers who are really advanced.

The DOS versions of programs are always easier to understand and never (or extremely rarely) need as many external dependencies and shared libraries as Linux.

So the great advantage is being able to have all of the relevant code packed into the source code of that DOS version; a single packed source code with no dependencies is necessary to study effectively. It's practical to bypass compile-time difficulties and installation of third-party libraries, and just get down to study the MPEG (1/2/3) decoder.

The intention is to have the simplest example (and run it in DOS or DOSBox) and port a newly-made version of a decoder in our own OS or any other one.