RipOff

How do I build RipOff from subversion?

First, do a subversion check out with

svn co https://svn.sourceforge.net/svnroot/ripoffc ripoffc

In order to make RipOff buildable you'll need to do a

aclocal; autoconf; automake -a

and that's it!

How do I get started on writing a RipOff plugin?

Downloading RipOffMp3Plugin.tar.gz from the RipOff downloads page is a great place to start. After that, the plugins folder in the main RipOff distrubution contains all the plugins written thus far and should get you started. The section below attempts to provide some documentation on the various parts of RipOff and should be helpful. You can also always e-mail me at brnewber____At____gmail_____dot___com for help as well.

RipOff Documentation for Developers

While RipOff isn't exactly object oriented, it does strive for encapsulation and modularity. I prefer to call it modular rather than object oriented.

RipOff is divided into the following modules:

RipOffCore

Talks to:

RipOffCore is in charge of the main GUI window that the user interacts with. This includes the track list, and the artist, cd title, year, and genre entry fields which are possible fields for how RipOff outputs its encoded files. RipOffCore is also in charge of bringing together all of the information in RipOffPreferences, the CDDB lookup code, the raw extracted CD audio, and the encoding plugins together to form the encoded file.

Specifically, when a CDDB lookup is performed (or the user manually changes fields in the cd track list) RipOff alters the data in the track list. Then when the user requests an extraction, it forms a track list that consists of RipOffTrack objects. RipOffCore then asks RipOffPreferences for the currently selected encoding plugin. The RipOffTrackList is sent to RipOffExtractor whose functionality is described below.

RipOffPreferences

Talks to:

RipOffPreferences is in charge of two major things: first it manages the user's preferences as to what criteria to use for file names of encoded files. Secondly, it manages the list of RipOffPlugins, requests to activate their preferences and about info, and which plugin is currently selected. RipOffCore, using ripoff_preferences_get_selected_plugin() can request the current plugin for use when it is encoding. RipOffCore also requests the file output information when it prepares to encode as well.

RipOffPreferences is periodically told to save its preferences. It does so using RipOffConfigFile. It also iterates through the list of plugins and informs each of them to do the same.

RipOffConfigFile

Talks to:

RipOffConfigFile is a collection of functions for saving different kinds of datafields. It is to be used by RipOffPreferences and RipOffPlugins. RipOffPlugins MUST provide a label that represents them for recalling and saving the data on disc.

RipOffPlugins

Talks to:

RipOffPlugins are actually just wrappers around RipOffRawPlugins which implement the RipOffRawPluginInterface. RipOffPlugin handles all the ugly dl_sym code so that when RipOffCore wishes to talk to plugins, it does not have to worry that underlying plugin is actually a shared library. RipOffRawPlugins must be implemented in ways RipOff expects which is documented in lib/RipOffPluginRawInterface.h

RipOffExtractor

Talks to:

RipOffExtractor is in charge of ripping audio from the inserted CD and passing the data along to the selected RipOffPlugin for encoding purposes. It is constructed with a RipOffTrackList as one of its data members. It iterates through this list and passes the plugin a file handle it has created whose location in the file system is determined by user preferences and the information contained in the particular RipOffTrack. The plugin uses the RipOffTrack to create appropriate metadata about the track. The file handle should not be operated on by RipOffPlugins beyond simple reading and writing. All open and close operations are handled by the RipOffExtractor.

CDDB lookup code

Talks to:

The CDDB lookup code is currently contained in the private function perform_cddb_lookup in RipOffCore.c In the future, the code should probably be seperated out into its own RipOffCDDBLookup module should the function get more complicated. It handles the cddb lookup and the accompanying GUI window.

Note on GUI code

At some point it would be desirable to fully seperate the GUI code in RipOffCore and RipOffPreferences from those modules and create a rendering module or a collection of rendering functionsfor those modules. Something to investigate is making RipOff's backend totally seperate from the GUI code thus allowing it to become either a library, or an application the supports multiple frontends. One major roadblock in this is RipOff's current dependency of glib, which in and of itself would not be difficult to cure. Also, RipOff currently stores all track data in a GtkTreeView. A GUI toolkit neutral solution would have to created in order to make RipOff's backend code fully seperate from the GUI (and one reason I haven't implemented this change before RipOff's initial release).

Still have questions or want to show your interest in developing for RipOff? Please post here