Table of Contents

Google Summer of Code Tasks

This page contains a subset of tasks from our main tasks section, specially selected for Google's Summer of Code. We also added some new tasks that we thought would be nice as tasks for GSoC. The list is split into tasks for the program library libhimd and for the GUI application qhimdtransfer.

General

We are using the popular revision control system git to manage our code base online. The code can be checked out with git any time with the command: 

git clone git://z6.physik.fu-berlin.de/linux-minidisc.git

Since you may not have yet write access to our source repository yet (read access is always possible), you should create patches with your code changes with the help of git and send them to the mailing list of this project. This wiki page explains how to create and manage patches using git: writeandsubmitpatch. The mailing list can be found here: https://lists.fu-berlin.de/listinfo/linux-minidisc.

Mentors and Contact

We have currently set two mentors. Adrian Glaubitz (glaubitz@physik.fu-berlin.de) and Michael Karcher (karcher@physik.fu-berlin.de). However, we have some more developers and other people involved in this project who will be happy to help you with understanding our current code and the hardware behind. There is a lot of documentation available in the wiki and you may always pop-in to our IRC channel (#linux-minidisc on FreeNode), join our mailing lists or mail questions or suggestions over e-mail. There is also a lot of knowledge and experience that we have accumulated in our heads. So if there is something you don't understand or that makes you wonder, just ask questions =).

We have added the estimated required expertise which is required to fulfill the tasks. We think that basic tasks can be achieved by anyone who has been working with the mentioned languages and toolkits for at least one year. Since students have up to 3 months to complete the tasks, we recommend that students choosing tasks marked as basic several of such tasks at the same time to keep them busy over the whole period of GSoC2010. Other (more difficult) tasks like implementing write support in libhimd should preferably be performed together with similar tasks like renaming, deleting and grouping support as we think that the knowledge and skills acquired with these tasks are very helpful when working on the related tasks. However, it's still up to the students what tasks they will select and we will happy to support them with whatever contributions they want to make to this project.

Tasks

libhimd

Task: Implement the renaming of tracks on the Hi-MD through the facilities of libhimd. This functionality will be used in qhimdtransfer so that users can rename their tracks on the Hi-MD. Implementing this code involves writing code which manipulates the TrackIndex file (see the_track-index_file) and writing the changes back to HiMD. Furthermore, in the frontend qhimdtransfer, code has to be implemented to call the new renaming functionality in the library, so that users can rename their tracks with an easy graphical user interface. Benefits: Users will be able to use a free software to edit the track names on their Hi-MD disks.

Task: Implement code which allows to delete tracks on a Hi-MD through the facilities of libhimd. This functionality will be used in qhimdtransfer so that users can delete MP3 tracks from a Hi-MD. Limit to MP3 tracks, as deleting other tracks involve updating the Sony DRM info. Implementing this code involves writing code which manipulates the TrackIndex file (see the_track-index_file) to remove all information of the corresponding track from the TrackIndex file and marking all associated blocks in the HMDHIFI.HMA file as unused. Furthermore, in the frontend qhimdtransfer, code has to be implemented to call the new deleting functionality in the library, so that users can delete their tracks with an easy graphical user interface. Benefits: Users will be able to use a free software to delete tracks from their Hi-MD disks.

Task: Implement code that rearranges track numbers on a Hi-MD medium in libhimd. Track moving is just rearranging numbers in the track number → physical track descriptor mapping table. This functionality will be used by qhimdtransfer to change the order of tracks, preferrably by a drag/drop interface. Benefits: Users will be able to use free software to change the order of tracks on their Hi-MD disks.

Task: Implement code to read/modify group info in libhimd. This functionality will be used in qhimdtransfer to show the tracks in a tree-shaped model within their groups and to drag/drop tracks between different groups. This depends on track moving, as only tracks next to each other can be put into the same group. Benefits: Users will be able to use free software to organize the tracks into groups on their Hi-MD disk.

Task: Implement code that splits tracks into two pieces at a certain point in time. Limit this to MP3 tracks as creation/deletion of non-MP3-tracks involves the dreaded Sony DRM stuff. Code in qhimdtransfer to choose a point in time by listening to the track is out-of-scope for this project, the intended interface is that fragment/block/frame of the split point is already given, a himddump interface suffices for GSoC. The objective of this tasks is to get acquainted to the creation of new tracks before transferring new tracks to Hi-MD is implemented. Benefits: Power users might be able to split tracks using himddump, a greatly improved QHiMDTransfer (with playback support) can use this functionality for user-friendly splitting. Standard users can at least use the join functionality to join tracks on their Hi-MD disk using free software.

Task: Implement code to allow transfer of new tracks onto a Hi-MD disk through the facilities of libhimd. This functionality will be used in qhimdtransfer so that users can transfer MP3 tracks to their Hi-MD Walkman. Implementing this code involves a number of steps until the actual MP3 data is written to the HiMD disk:

  1. cut the mp3 file into frames.
  2. gather the frames into blocks of 16384-64=16320 Bytes.
  3. obfuscate these blocks with the track/disc specific MP3 encoding key
  4. write these blocks into one or more contiguous chunks in the ATDATAxx.HMA file
  5. write fragment entries for the contiguous chunks into the fragment table in the TRKIDXxx.HMA file (experience with handling fragments is present from split/join/delete)
  6. write a track entry that points to the first fragment entry (experience with handling track entries is present from rename/split/join/delete).
  7. add the track to the main track descriptor index list (experience with this list is present from delete/move/split/join)

Thus, essentially, writing a track to a HiMD involves only cutting the source MP3 file with the help of the library libmad into frames, then gather these frames into block sizes of 16384-64=16320 Bytes (because 32 Bytes are required for a header and a footer block), obfuscating the frames with a simple algorithm and then finally writing the data onto the HiMD and adding an appropriate entry to the TrackIndex file.

Task: Write a plugin for the popular GNOME media player application rhythmbox to support HiMD Walkman. This requires knowledge of the plugin API of rhythmbox in order to implement bindings to libhimd. Since libhimd is written completely platform-independent in C and does not require privileged access to the hardware (only file-based access to the FAT filesystem on the HiMD is required), it's not necessary to have knowledge in driver or any other low-level programming techniques. In fact, simple disk images (created with dd) of HiMD can be used to simulate a connected HiMD Walkman to test the code. Benefits: Users of rhythmbox (which is the default media player for GNOME and major Linux distributions like Fedora and Ubuntu) will be able to synchronize (up to now, only transfers from the HiMD Walkman to the PC are implemented in libhimd, transfers to the Walkman are a separate task for GSoC 2010) their HiMD Walkman with their favourite media player.

Task: Create code for a plugin which uses libhimd to access a HiMD Walkman from the KDE media player amarok. This requires good knowledge of C/C++,KDE development as well as the plugin API of amarok. Since libhimd is written completely platform-independent in C and does not require privileged access to the hardware (only file-based access to the FAT filesystem on the HiMD is required), it's not necessary to have knowledge in driver or any other low-level programming techniques. In fact, simple disk images (created with dd) of HiMD can be used to simulate a connected HiMD Walkman to test the code. Benefits: Users of amarok (which is the default music player for KDE and major Linux distributions like openSUSE and KUbuntu) will be able to synchronize (up to now, only transfers from the HiMD Walkman to the PC are implemented in libhimd, transfers to the Walkman are a separate task for GSoC 2010) their HiMD Walkman with their favourite music player.

Task: HiMD Walkman present themselves as USB mass storage devices (which are formatted with a FAT filesystem by default) when connecting them to a PC over USB. Most of the data operation, that is transferring tracks from the HiMD medium and to it, can be handled with simple file-based I/O. However, there are a few functions in the HiMD Walkman which can only be accessed through SCSI commands (SCSI-over-USB to be more exact). These include formatting a HiMD (see: basictools/himdformat.c in the git repository), reading the diskid (see: the_diskid) and many more. We have already reverse-engineered all the commands (see: himdscsi) and also written some example code demonstrating these SCSI commands on Linux. It would be very nice, however, to have this SCSI-functionality implemented platform-independent into libhimd. The original idea was to use libschily to implement the SCSI support layer. However, we have found a new, better and easier solution using code from the dvd+rw-tools (see: https://lists.fu-berlin.de/pipermail/linux-minidisc/2010-December/msg00000.html). Benefits: Users will be able to access all functionality beyond transferring audio to and from the disk of their HiMD devices with free software.

libnetmd

Task: Port the python code in netmd/upload.py (see: netmdpython) to C, or better add the functionality of upload.py to the C library libnetmd (see: http://sourceforge.net/projects/libnetmd/). This involves both knowledge in Python and C. Porting the Python code of upload.py will add support for the populuar upload functionality of the Sony MZ-RH1 Walkman to libnetmd allowing users to backup all their old MiniDiscs with an easy to use GUI on all supported platforms. Since the future plan is to have two C libraries (libhimd for HiMD support and libnetmd for NetMD support) which are used by GUI applications or plugins for media players like rhythmbox, Songbird or amarok, porting the Python code of upload.py to the C library would fit perfectly into the roadmap of this projects software. An existing, early implementation of this library can be found here: http://users.physik.fu-berlin.de/~glaubitz/linux-minidisc/mdlib.tar.gz Benefit: Users will be able to backup their old MiniDisc recordings with a free software on nearly all operating systems and not just Windows/32-Bit.

QHiMDTransfer

Task: Implement code in qhimdtransfer to allow export of the track listing of a HiMD to an XML file. This involves understanding the format of the tracklist file on the HiMD filesystem (see the_track-index_file) and basic knowledge of XML. Alternatively, any other non-proprietary (markup-/text-)file format is welcome. However, XML has the advantage that it can be imported by most applications which can process tabular data like these. Benefits: Users can create disk catalogues of their HiMD recordings to import and manage the catalogue data in a database which is very helpful when cataloguing large collections of HiMDs and later on standard MiniDiscs as well (once QHiMDTransfer has also support for NetMD).

Task: Use the existing code in QHiMDTransfer, himdscsitest and himddump to create a complete command line version of the transfer software. This involves a lot of code moving and clean-up but it's a task which can be performed with basic C programming knowledge. To improve user experience, a manpage for the command line version should be written as well (using nroff format). Benefits: Provides a fully scriptable command line version, primarily targeted at Unix power users.

Task: Create ready-installable RPM packages by creating a specs file according to http://fedoraproject.org/wiki/PackageMaintainers/CreatingPackageHowTo (openSUSE: http://developer.novell.com/wiki/index.php/SUSE_Package_Conventions, Mandriva: http://wiki.mandriva.com/en/Development/Howto/RPM). This involves reading and understanding the appropriate packaging guides from Fedora (openSUSE, Mandriva) and creating the necessary specs file which will finally build the RPM package. Benefits: Allows the software to be uploaded and distributed to the aforementioned Linux distributions so that the users of these distributions can easily install and update qhimdtransfer with the package manager shipped by their distribution.

Task: Make the source code ready to be built and run on Haiku. Since we have not tested the software on Haiku yet, we cannot really say how much time and efforts it will take to get the software running. However, since there are already ports of all libraries by qhimdtransfer and libhimd (especially Qt) to Haiku, it should be feasible to get things running. This task also involves writing build instructions for Haiku (see: compilingonhaiku) which explain in detail what packages will have to be installed on a freshly installed version of Haiku to be able to clone the git repository and build the code from source. Benefits: Users of the Haiku operating system will be able to connect and use their HiMD devices with their operating system of choice.

Task: Leverage the version control capabilities of our git repository to automatically determine the version number of qhimdtransfer during build. For this, the qmake project file has to be extended to read the current version from git describe command, see: http://www.qtcentre.org/wiki/index.php?title=Version_numbering_using_QMake. For the case that the application is build from a tarball source, i.e. outside git, a fallback file called RELEASE should be in the root of the source tree to give the release version number. This makes especially sense since tarballs will always be produced for release versions while the development source stays within git. The version number determined should both be displayed in the about dialog of the application as well as used for the automatic updates. Benefits: A proper versioning is mandatory for every larger software project so QHiMDTransfer should have one as well. Also, it is required for the planned automatic updates on Windows and MacOS X.

Task: Extend qhimdtransfer with the functionality of automatic updates on Windows and/or MacOS X. This functionality is solely part of qhimdtransfer and allows for automatic updates of the installed software. Preferably, the updater works in a similar manner like the one in VLC media player. Both the Mac and the Windows version offer a menu item "Check for Updates" which queries an URL specified in the source code or configuration settings for an updated version on the servers and automatically downloads them. Qt provides the required functionality to make http queries with the classes QNetworkAccessManager and QNetworkReply. Other implementations are welcome as well, even though Qt is always preferred as this is the framework the whole application is based on. A very easy and alternative implementation on MacOS X would be using and integrating Sparkle with Qt, see: http://el-tramo.be/blog/mixing-cocoa-and-qt. In fact, there is also a Windows version of Sparkle available, called WinSparkle. Benefits: Users will be able to automatically update the installed version of qhimdtransfer on their Windows and MacOS computers. (Linux and other Unix-based operating systems don't need this functionality as they usually install all software over a package manager anyway.)