Bug#115061: ITP: jack -- rip and encode CDs with one command

[Michael Banck <mbanck@gmx.net>]

Package: wnpp
Severity: wishlist
License: gpl
Url: http://home.t-online.de/home/mbanck/debian/
Description: rip and encode CDs with one command
 Jack has been developed with one main goal: making MP3s or OGGs
 without having to worry. There is nearly no way that an incomplete rip
 goes unnoticed, e.g. jack compares WAV and MP3 filesizes when
 continuing from a previous run. Jack also checks your HD space before
 doing anything (even keeps some MB free).  
 .  
 Jack is different from other such tools in a number of ways:
  - it supports different rippers and encoders
  - it is very configurable
  - it doesn't need X
  - it can "rip" virtual CD images like the ones created by cdrdao
  - when using cdparanoia, cdparanoia's status information is displayed
    for all tracks, so you can see if something went wrong
  - it uses sophisticated disk space management, i.e. it schedules it's
    ripping/encoding processes depending on available space.
  - freedb query, file renaming and id3 tagging
  - it can resume work after it has been interrupted. If all tracks have
    been ripped, it doesn't even need the CD anymore, even if you want 
    to do a freedb query.
  - it can do a freedb query based on MP3s alone, like if you don't
    remember from which CD those MP3s came from.
  - freedb submissions 


Jack finally includes ogg/vorbis support in CVS now, so it can be
packaged.

On a related note: Is it feasable to create a virtual 'mp3-encoder'
package? This would change jack's control from 'Recommends: vorbis-tools'
to 'Depends: $DEPENDS, vorbis-tools | mp3-encoder' which looks much
cleaner IMO. Of course, using ogg/vorbis should be encouraged, but
a lot of users depends on mp3 for their portable players etc.

There are some mp3-encoders out there who can't be in the debian
archive, but are packaged locally nevertheless. They could provide
'mp3-encoder' and thus other mp3-encoding software could be packaged.

I haven't thought about this very long and might have missed an
important point though.

regards,

Michael