DokuWiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 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:
<code>
git clone git://z6.physik.fu-berlin.de/linux-minidisc.git
</code>
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 =).

===== Skill levels and related tasks =====

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 ===

  * Renaming tracks support - Required expertise: **Advanced**
    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 [[himddiskformat#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.

  * Deleting MP3 tracks support - Required expertise: **Advanced**
    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 [[himddiskformat#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.

  * Support track moving - Required expertise: **Basic**
    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.

  * Support grouping - Required expertise: **Advanced**
    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.

  * Support split/join MP3 tracks - Required expertise: **Advanced to Expert**
    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.

  * Writing MP3 tracks support - Required expertise: **Expert**
    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:

  - cut the mp3 file into frames.
  - gather the frames into blocks of 16384-64=16320 Bytes.
  - obfuscate these blocks with the track/disc specific MP3 encoding key
  - write these blocks into one or more contiguous chunks in the ATDATAxx.HMA file
  - 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)
  - write a track entry that points to the first fragment entry (experience with handling track entries is present from rename/split/join/delete).
  - 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.

  * Write libhimd plugin support for rhythmbox - Required expertise: **Advanced**
  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.

  * Write libhimd plugin support for amarok - Required expertise: **Advanced**
  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.

  * Implement SCSI-device support into libhimd - Required expertise: **Expert**
    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: [[himddiskformat#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 [[http://developer.berlios.de/projects/libschily/|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 ===

  * Port Sony MZ-RH1 Python upload script to libnetmd - Required expertise: **Advanced** (both C and Python knowledge)
  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 ===

  * Export tracklists to XML files - Required expertise: **Basic**
    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 [[himddiskformat#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). 

  * Create command line version - Required expertise: **Basic**
    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.

  * Create RPM packages for Fedora (alternatively openSUSE, Mandriva) - Required expertise: **Basic**
    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.

  * Create Haiku port - Required expertise: **Advanced**
    Task: Make the source code ready to be built and run on [[http://www.haiku-os.org|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.

  * Versioning of QHiMDTransfer - Required expertise: **Basic**
    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.

  * Integrate Automatic Updates - Required expertise: **Advanced**
    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 [[http://www.videolan.org/|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 [[http://doc.qt.nokia.com/4.7/qnetworkaccessmanager.html|QNetworkAccessManager]] and [[http://doc.qt.nokia.com/4.7/qnetworkreply.html|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 [[http://sparkle.andymatuschak.org/|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 [[http://winsparkle.org/|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.//)