| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| googlesummerofcode [2010/11/23 21:26] – glaubitz | googlesummerofcode [2013/05/16 11:39] (current) – [General] glaubitz |
|---|
| 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: | 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> | <code> |
| git clone git://minidisc.dyndns.org/linux-minidisc | git clone git://z6.physik.fu-berlin.de/linux-minidisc.git |
| </code> | </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]]. | 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]]. |
| 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: | 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: |
| |
| <code> | - cut the mp3 file into frames. |
| 1) Cut the mp3 file into frames. | - gather the frames into blocks of 16384-64=16320 Bytes. |
| 2) Gather the frames into blocks of 16384-64=16320 Bytes. | - obfuscate these blocks with the track/disc specific MP3 encoding key |
| 3) 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 |
| 4) 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) |
| 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) | - write a track entry that points to the first fragment entry (experience with handling track entries is present from rename/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). | - add the track to the main track descriptor index list (experience with this list is present from delete/move/split/join) |
| 7) Add the track to the main track descriptor index list (experience with this list is present from delete/move/split/join) | |
| </code> | |
| |
| 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. | 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. |
| |
| * Implement SCSI-device support into libhimd - Required expertise: **Expert** | * 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//, thus not using the SCSI programming API of a certain operating system but using the libraries here [[http://developer.berlios.de/projects/libschily/|libschily]] to implement SCSI for all operating systems supported by these SCSI libraries. A sample implementation can be found in //himdscsitest.c//.**Benefits**: Users will be able to access all functionality beyond transferring audio to and from the disk of their HiMD devices with free software. | 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 === | === libnetmd === |
| |
| * Port Sony MZ-RH1 Python upload script to libnetmd - Required expertise: **Advanced** (both C and Python knowledge) | * 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. **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. | 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 === | === QHiMDTransfer === |
| * Create Haiku port - Required expertise: **Advanced** | * 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. | 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** | * 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. **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.//) | 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.//) |
