Crash during tag update phase

  • trames

    trames - 2010-04-04

    I have just discovered ripperX.  I am ripping and encoding several Classical CDs.  Many of them have long track names (not sure that matters).  The encoding portion fails at the very end when apparently it is updating the Tag information.  The strange thing is that the first 9 tracks always update without error.  When it gets to the 10th track and above it crashes.  This also happens when I just select a single track above the 9th.  The mp3 files play OK, but the track information is missing.  I then have to use easytag to update tracks 10 and above.

    I am using the lame mp3 encoder.  I tried the ogg/vorbis, and do NOT get any errors. Works perfectly.  Of course, I want MP3s :)

    Just for giggles I tried the toolame encoder.  Got the same crash.

    openSuse 11.1, lame 3.98.4, ripperX 2.72

  • ptdcho

    ptdcho - 2010-04-11

    I have the same system (openSuse 11.1, lame 3.98.4, ripperX 2.72 from Packman repository,  (x86_64)) and got the same crash. No idea how to fix it, yet.

  • trames

    trames - 2010-05-12

    Just wanted to add that this happens when ripping several CDs without closing ripperX.  If I close between each CD, at least after the last 30 that I have done, it has not failed.

  • Dave Kaye

    Dave Kaye - 2010-05-13

    I use openSUSE 11.2 and tested ripperX.  It will crash immediately at the first tag, not just after the first 9 tags.  RipperX uses the id3lib program to add ID3 tags to mp3 files.  There is a bug in shipping versions of this library in openSUSE 11.2 and also in version 11.1.  There is an updated file in the repositories for multimedia for each version which corrects this bug.

    The bug only happens when a non-tag containing mp3 file which was created using variable bit rate encoding is accessed to add tags.  If you use constant bit rate encoding, no crash.  If you create an initial tag using LAME by adding a -ta or -tc to the optional parameters box, no crash even when using variable bit encoding.  This crash is not unique to ripperX, I found other software packages using the id3lib program also crash at the same point/circumstances.

    This may be the cause of the 9+ tags crash.  Older versions of the ripperX did not crash and the new 2.7.2 will not crash once I got the id3lib straighten out.   My test CD was 15 songs long.

    As to the need to restart after every CD.  There are multiple bugs in the track filename structure in ripperX, as well as re-initializing the system after a new CD is entered.  They are all repairable, but until the code is fixed the easiest way to guarantee success is to do individual CDs and restart the program after every one.  You may or may not experience a crash, it is tied to variable initialization which is dependent upon what you have just done.


Log in to post a comment.