The 8Hz encoder was written with no concern for being thread safe. In it's original form, it is a mess of global and static variables. Since KonaKoder is capable of encoding multiple songs at once on a multiprocessor machine, this had to be changed. To acheive this, the encoder has been transformed into a C++ class with all global variables being instance members of the class. This allows KonaKoder to simply create an MP3Encoder object for each processor. The MP3Encoder class is a child of the BLooper class, so it runs in it's own thread. All communication is via BMessages. It can accept commands to create a new file, and to close the current file. It also accepts BMessages which contain blocks of audio data to be encoded. Upon receiving one of these blocks, it compresses it and adds it to the currently open file. After it finishes processing the block, it replies to the BMessage to ask for the next block of data.
The process of reading audio data is a little more involved. The CDInterface class is designed to be able to feed audio data to multiple MP3Encoder objects. To accomplish this, it maintains a list of CDSession objects. The first step is to send it a BMessage telling it to create a new session. The message needs to specify which track to read and which MP3Encoder to send the data to. Once the session is created, the MP3Encoder can begin sending BMessages requesting blocks of audio data. After the song is encoded, the session should be closed with the appropriate message.
Each CDSession maintains state including the track it's reading, the first and last frame of the track, the next frame to send, and the MP3Encoder to send the data to. A CDSession also maintains a buffer of audio data to reduce the number of accesses to the CD player. Currently, it buffers 150 frames of audio data at a time.
The CDInterface class also tries to ensure that the audio data is error free. Initially, it simply read the audio data from the CD and assumed it was correct. However, I found that some slightly damaged CD's would produce MP3 files with skips in them. It turns out that the CD player would occasionally return data from the wrong portion of the track, resulting is MP3 files that were jumbled in places. In order to work around this, CDInterface actually reads the data twice and compares the results. If they match the data is sent to the MP3Encoder. If they differ, it re-reads the data and tries again. It will continue to re-read the data until the number of differences falls below a certain threshold. While this slows down the encoding process, it produces much better results.
int32 Audio:Track string Audio:Artist string Audio:Album string Audio:Genre string Audio:Title int32 Audio:YearThe template directory is another nice feature which unfortunately relies on some not very well documented magic. It relies on the fact that the Tracker saves the layout of a directory in attributes attached to the directory itself. KonaKoder simply copies these attributes from the template directory to the new directories it creates. This should always work, but it's possible that it will break at some point in the future if the Tracker changes the name of the attributes it uses. However, here is a list of the attributes that get copied. To be honest, I'm not sure exactly what data is in what attributes so KonaKoder just copies them all:
_trk/columns Column layout on PPC _trk/columns_le Column layout on Intel _trk/viewstate Setting of "View" option on PPC _trk/viewstate_le Setting of "View" option on Intel _trk/windframe Position and Size of windowFor details on how KonaKoder teaches the Tracker how to display MP3 attributes, take a look at the member function EncoderApp::CheckIndexes(). Note that KonaKoder takes special care to not remove any attributes that already existed. This is an easy mistake to make, and is sure to irritate users.
Copyright 1999 David Mitchell