ripperX scm Bug Feedback

[SamK]

Ripping
TCZ
Installed rippex.tcz and lame.tcz
Rip to mp3
Successfully rips to wav file
Successfully rips to mp3 file

Reboot to unload tczs

SCM
Rip to mp3
Successfully rips to wav file
Fails to properly create mp3 - just a few Kb in size and an m3u file.

Load local lame.tcz via AppBrowser

Rip to mp3
Successfully rips to wav file
Successfully rips to mp3 file

It seems that the scm cannot find/use its inbuilt lame.


Missing Icon
Best explained by the attached screen shot

   
 

GTK1
There is also a gtk1 version in the repo. Should be roughly half the size of the gtk2 version.  Is there value in making an scm of it?

[Jason W]

I had also spent some time with this one a few days ago, and it works here.  My md5:

b5d1651031fbfcc52e7ebb85db08809f  ripperx.scm

[SamK]

I had also spent some time with this one a few days ago, and it works here.  My md5:

b5d1651031fbfcc52e7ebb85db08809f  ripperx.scm

Your and my md5s match.


Re-tested Ripping/Encoding without loading lame.tcz
Results:
Rip to wav=OK
Rip/encode to flac=OK
Rip/encode to ogg=OK
Rip/encode to mp3=Fail
Invalid mp3 files are produced.  Each is 2.0k.

Re-rip/encode same files to mp3 after loading lame.tcz
Results:
Rip/encode to mp3=OK
Valid mp3 files are produced of the correct size
   

[Jason W]

Though I did not have lame.tcz installed and it still worked, I will retest.

[SamK]

Any news on this?

As reported in reply #2 rips all OK except mp3.  Invalid mp3s are produced each 2k in size.

Test environment onboot.lst

Code: [Select]

Xvesa.tcz
Xprogs.tcz
kmaps.tcz
jwm.tcz

[Jason W]

It is still working.  But be sure to select a writable target directory in the Config tab.

[SamK]

It is still working.  But be sure to select a writable target directory in the Config tab.

I am confident it is not a rights issue as otherwise the wav, ogg and flac files would not be written as they all use the same location.

As a double check, the scm and md5 files were deleted together with /home/tc/.ripperXrc.  The scm was then freshly downloaded from ibiblio.  The md5 verified OK.  The only packages installed other than ripperX are the tczs in onboot.lst as described in reply #4.  The ripper target directory was pointed to /home/tc to exclude any writing issues.
Results
Successfully rips to wav
Successfully rips to wav and successfully encodes to flac
Successfully rips to wav and successfully encodes to ogg
Successfully rips to wav but fails to encode to mp3

The matter seems to be in some way related to the encoding of the mp3 from the ripped wav.  RipperX does not run this part of the cycle when creating an mp3.  An mp3 file is always produced but it is always invalid always having a file size of 2k irrespective of the size of the input file.  The wav, flac, and ogg files always produce correct files with an appropriate file size in each case. 

To verify that it is encoding the mp3 that is the problem, lame.tcz was then installed.  In this state ripperX successfully rips to wav and successfully encodes to mp3.

This pattern is consistent using different machines and different downloads of the scm and different input sources. 



Could we agree to run TC with the same packages loaded (onboot tczs and scms) on each of our respective machines?  (something similar to the way cloud mode is used to test tcz creation).  I would favour something very minimal and also clean downloads of scms from the same repo rather than relying on local copies.  This will hopefully eliminate as many variables as possible.  Can you see an alternative way forward?

It might also be helpful if another member might test and report their findings.
 

[Jason W]

Ok, I see it when using the same onboot.lst.

I will have time Wed. evening to look more into it.  I ran an ldd on the lame binary and library and nothing appeared to be missing in the extension, but evidently there is more to it.

[Jason W]

Ripperx is wanting ncurses installed in the normal path, and is not working with a rebuilt one in the extension.  I will rebuild ripperx straight from source when I get a chance, and that will likely solve the issue.

[SamK]

Thanks for the progress report.
   

[Jason W]

The lame binary in the extension simply needed a wrapper, like with asunder something I would normally catch quicker.  Hopefully is fixed now.

[SamK]

Hopefully is fixed now.

Unfortunately I cannot test it. The scm had been deleted and had to be downloaded again which consistently produces the following:

Code: [Select]

ls -1l ripperx.scm*
-rw-r--r--    1      4096 Apr 27 07:08 ripperx.scm
-rw-r--r--    1        46 Apr 27 07:08 ripperx.scm.md5.txt

[SamK]

Unfortunately I cannot test it.

I tracked the the matter down to a lack of space on the small flash drive used during testing.  Deleting all the wav files left over from previous tests resolved the problem.

Reporting success
RipperX now works as expected.