rubyripper - Project Hosting on Google Code

Yesterday 45 hours ago issue 371 (Last File Rip Reports "Filesize is not correct! Trying anoth...) commented on by nickbryda - Ubuntu 9.04 rubyripper 0.5.7 DVDRAM GSA-T20L offset 667 fails on the last track with "Filesize is not correct!". Setting the offset to 0 makes it rip the last track fine. Ubuntu 9.04 rubyripper 0.5.7 DVDRAM GSA-T20L offset 667 fails on the last track with "Filesize is not correct!". Setting the offset to 0 makes it rip the last track fine. Last 7 days Jan 03, 2010 issue 353 (Allow the user to define the playlist filename) commented on by PtKizc - I also would find this quite useful. Also, it would be nice (for me, at least) to be able to specify a separate path for the m3u files, as I prefer to store them separately from the actual encoded tracks. Thanks. I also would find this quite useful. Also, it would be nice (for me, at least) to be able to specify a separate path for the m3u files, as I prefer to store them separately from the actual encoded tracks. Thanks. Jan 03, 2010 issue 392 (Delay after closing tray) reported by rjbell4 - 1) What version of rubyripper are you using? On what operating system? -> 0.5.5 2) Are you using the gtk2 or the commandline interface? -> gtk2 Please provide any additional information below. After hitting "Close tray", rubyripper waits for the tray to close, and then reports that there is no audio disc. In reality, rubyripper just needs to wait a few more seconds for the CD to be recognized. I get around this my manually pressing "Scan CD" in a few seconds. It would be nice if rubyripper was smart enough to wait until the CD was ready to read the contents. 1) What version of rubyripper are you using? On what operating system? -> 0.5.5 2) Are you using the gtk2 or the commandline interface? -> gtk2 Please provide any additional information below. After hitting "Close tray", rubyripper waits for the tray to close, and then reports that there is no audio disc. In reality, rubyripper just needs to wait a few more seconds for the CD to be recognized. I get around this my manually pressing "Scan CD" in a few seconds. It would be nice if rubyripper was smart enough to wait until the CD was ready to read the contents. Jan 02, 2010 issue 391 (Split out "bonus songs") commented on by mordbrann - I believe this is outside the scope of rubyripper. rr just rips and compares tracks to get a secure copy - it doesn't what the audio sounds like. I think there are some programs that will split an audio file based on silence, but I can't remember any names. You could also open the file up with the open source sound editor Audacity, and save the tracks that way. You'd probably want to rip the tracks as wav, then encode later as resaving a lossy format (like mp3) would result in worse audio quality. HTH I believe this is outside the scope of rubyripper. rr just rips and compares tracks to get a secure copy - it doesn't what the audio sounds like. I think there are some programs that will split an audio file based on silence, but I can't remember any names. You could also open the file up with the open source sound editor Audacity, and save the tracks that way. You'd probably want to rip the tracks as wav, then encode later as resaving a lossy format (like mp3) would result in worse audio quality. HTH Jan 02, 2010 issue 391 (Split out "bonus songs") reported by rjbell4 - It would be great if there was some option to be able to split "bonus songs" out as separate files. I have a number of CDs where the last track is a song, extended silence, and then the "bonus song". It would be great to split that out. I admit I have no idea what this would entail. It would be great if there was some option to be able to split "bonus songs" out as separate files. I have a number of CDs where the last track is a song, extended silence, and then the "bonus song". It would be great to split that out. I admit I have no idea what this would entail. Jan 02, 2010 issue 390 (Notification of completion) reported by rjbell4 - 1) What version of rubyripper are you using? On what operating system? -> 0.5.5 2) Are you using the gtk2 or the commandline interface? -> gtk2 Please provide any additional information below. I'd like to see an option to provide notification of completion. Ejecting the CD is one option, but I like to disable this, in case I'm away from my computer at the time the rip is completed. Simply playing an audio file would suffice. 1) What version of rubyripper are you using? On what operating system? -> 0.5.5 2) Are you using the gtk2 or the commandline interface? -> gtk2 Please provide any additional information below. I'd like to see an option to provide notification of completion. Ejecting the CD is one option, but I like to disable this, in case I'm away from my computer at the time the rip is completed. Simply playing an audio file would suffice. Jan 02, 2010 issue 353 (Allow the user to define the playlist filename) commented on by rjbell4 - I second this. The default format is mostly okay for me, though I'd like to strip out the " (codec)" at the end. Having this be configurable like the rest of the filenames would make sense. I second this. The default format is mostly okay for me, though I'd like to strip out the " (codec)" at the end. Having this be configurable like the rest of the filenames would make sense. Last 30 days Dec 30, 2009 issue 348 (Excessive time between ripping tracks ) commented on by finnpant...@yahoo.com - I recently began having this same problem. It rips the two trial wavs very quickly, then begins the "analyzing files for mismatching chunks" phase which takes forever. I'm not sure at what point exactly did this behavior begin, I think everything was fine just a couple of weeks ago. Maybe I'll try downgrading something and see if it helps. System is Gentoo with Rubyripper 0.5.7. I recently began having this same problem. It rips the two trial wavs very quickly, then begins the "analyzing files for mismatching chunks" phase which takes forever. I'm not sure at what point exactly did this behavior begin, I think everything was fine just a couple of weeks ago. Maybe I'll try downgrading something and see if it helps. System is Gentoo with Rubyripper 0.5.7. Dec 28, 2009 issue 375 (Faster ripping possible?) commented on by mordbrann - This sounds like a dupe of http://code.google.com/p/rubyripper/issues/detail?id=348 This sounds like a dupe of http://code.google.com/p/rubyripper/issues/detail?id=348 Dec 28, 2009 issue 112 (Feature req: Accuraterip style verification (www query of c...) commented on by bishop.mark.gardner - It seems to me that the best way to bootstrap an open-source database is to use AR but also submit it to the new database once it is validated with AR. After a while, the new database would be able to stand on its own. It seems to me that the best way to bootstrap an open-source database is to use AR but also submit it to the new database once it is validated with AR. After a while, the new database would be able to stand on its own. Dec 22, 2009 issue 389 (rrip_cli --version : "fat" output) reported by lolilolicon - What steps will reproduce the problem? 1. run rrip_cli --version at terminal. What is the expected output? What do you see instead? ------------------------------------------------------------------------ $ rrip_cli --version Rubyripper version 0.6.0b2. exit Usage: rrip_cli [options] -V, --version Show current version of rubyripper. -f, --file <FILE> Load configuration settings from file <FILE>. -v, --verbose Display verbose output. -c, --configure Change configuration settings. -a, --all Rip all tracks. Skip any questions about track selection. -h, --help Show this usage statement. ------------------------------------------------------------------------ Why does the --version switch print exit and the help info? I took a look at rrip_cli(rubyripper_cli.rb) but couldn't see no reason for this behavior. I'm interested what could have caused this. ------------------------------------------------------------------------ 1) What version of rubyripper are you using? On what operating system? -> 0.6.0b2, fresh from git. $ ruby -v ruby 1.9.1p376 (2009-12-07 revision 26041) [i686-linux] 2) Are you using the gtk2 or the commandline interface? -> cli What steps will reproduce the problem? 1. run rrip_cli --version at terminal. What is the expected output? What do you see instead? ------------------------------------------------------------------------ $ rrip_cli --version Rubyripper version 0.6.0b2. exit Usage: rrip_cli [options] -V, --version Show current version of rubyripper. -f, --file <FILE> Load configuration settings from file <FILE>. -v, --verbose Display verbose output. -c, --configure Change configuration settings. -a, --all Rip all tracks. Skip any questions about track selection. -h, --help Show this usage statement. ------------------------------------------------------------------------ Why does the --version switch print exit and the help info? I took a look at rrip_cli(rubyripper_cli.rb) but couldn't see no reason for this behavior. I'm interested what could have caused this. ------------------------------------------------------------------------ 1) What version of rubyripper are you using? On what operating system? -> 0.6.0b2, fresh from git. $ ruby -v ruby 1.9.1p376 (2009-12-07 revision 26041) [i686-linux] 2) Are you using the gtk2 or the commandline interface? -> cli Dec 22, 2009 AccurateRip_Research (Please help to collect info about AccurateRip (issue 112)) Wiki page commented on by jonlst - Documentation on the AccurateRip algorithm: http://sourceforge.net/userapps/wordpress/jonls/2009/10/28/calculating-accuraterip-checksums/ Documentation on the AccurateRip algorithm: http://sourceforge.net/userapps/wordpress/jonls/2009/10/28/calculating-accuraterip-checksums/ Dec 17, 2009 issue 388 (All user to specify temp file location) reported by hansonor...@verizon.net - What steps will reproduce the problem? n/a What is the expected output? What do you see instead? Would like to have the option to specify where temp files are stored. 1) What version of rubyripper are you using? On what operating system? -> git as of 2009-12-17 2) Are you using the gtk2 or the commandline interface? -> n/a 3) Is the problem gone with the default settings? If so, please attach your settings file ($HOME/.rubyripper/settings). -> no 4) Does the problem only happen on a specific disc? If so, please attach the output of cdparanoia -Q. Also the freedb output would be nice if it may be related to it. -> n/a Please provide any additional information below. I can manually override the default by editing line 661 of rr_lib.rb, but it would be nice if I could specify it in settings. What steps will reproduce the problem? n/a What is the expected output? What do you see instead? Would like to have the option to specify where temp files are stored. 1) What version of rubyripper are you using? On what operating system? -> git as of 2009-12-17 2) Are you using the gtk2 or the commandline interface? -> n/a 3) Is the problem gone with the default settings? If so, please attach your settings file ($HOME/.rubyripper/settings). -> no 4) Does the problem only happen on a specific disc? If so, please attach the output of cdparanoia -Q. Also the freedb output would be nice if it may be related to it. -> n/a Please provide any additional information below. I can manually override the default by editing line 661 of rr_lib.rb, but it would be nice if I could specify it in settings. Dec 10, 2009 issue 387 (Some CD's Crash With Freedb MD Fetching Enabled) reported by theknigh...@gmail.com - What steps will reproduce the problem? 1. Starting Rubyripper with one of those cd's 2. Pressing Scan Drive What is the expected output? What do you see instead? warning: discid or cd-discid isn't found on your system! Using fallback... /usr/lib/ruby/site_ruby/1.9.1/rr_lib.rb:513:in `checkDataTrack': undefined method `find_all' for #<String:0x00000002d44218> (NoMethodError) from /usr/lib/ruby/site_ruby/1.9.1/rr_lib.rb:499:in `getFreedbString' from /usr/lib/ruby/site_ruby/1.9.1/rr_lib.rb:486:in `getDiscInfo' from /usr/lib/ruby/site_ruby/1.9.1/rr_lib.rb:285:in `initialize' from /usr/bin/rrip_gui:195:in `new' from /usr/bin/rrip_gui:195:in `block in scan_drive' 1) What version of rubyripper are you using? On what operating system? -> rubyripper-git-20091128 on an uptodate Arch Linux 2) Are you using the gtk2 or the commandline interface? -> gtk2 3) Is the problem gone with the default settings? If so, please attach your settings file ($HOME/.rubyripper/settings). -> no 4) Does the problem only happen on a specific disc? If so, please attach the output of cdparanoia -Q. Also the freedb output would be nice if it may be related to it. -> Some work, some don't. here's one that doesn't work: cdparanoia III release 10.2 (September 11, 2008) Table of contents (audio tracks only): track length begin copy pre ch =========================================================== 1. 14119 [03:08.19] 0 [00:00.00] no no 2 2. 20224 [04:29.49] 14119 [03:08.19] no no 2 3. 24697 [05:29.22] 34343 [07:37.68] no no 2 4. 22450 [04:59.25] 59040 [13:07.15] no no 2 5. 21606 [04:48.06] 81490 [18:06.40] no no 2 6. 21354 [04:44.54] 103096 [22:54.46] no no 2 7. 30267 [06:43.42] 124450 [27:39.25] no no 2 8. 19965 [04:26.15] 154717 [34:22.67] no no 2 9. 20173 [04:28.73] 174682 [38:49.07] no no 2 10. 21850 [04:51.25] 194855 [43:18.05] no no 2 11. 21314 [04:44.14] 216705 [48:09.30] no no 2 TOTAL 238019 [52:53.44] (audio only) Please provide any additional information below. With Freedb MD Fetching disabled everything works What steps will reproduce the problem? 1. Starting Rubyripper with one of those cd's 2. Pressing Scan Drive What is the expected output? What do you see instead? warning: discid or cd-discid isn't found on your system! Using fallback... /usr/lib/ruby/site_ruby/1.9.1/rr_lib.rb:513:in `checkDataTrack': undefined method `find_all' for #<String:0x00000002d44218> (NoMethodError) from /usr/lib/ruby/site_ruby/1.9.1/rr_lib.rb:499:in `getFreedbString' from /usr/lib/ruby/site_ruby/1.9.1/rr_lib.rb:486:in `getDiscInfo' from /usr/lib/ruby/site_ruby/1.9.1/rr_lib.rb:285:in `initialize' from /usr/bin/rrip_gui:195:in `new' from /usr/bin/rrip_gui:195:in `block in scan_drive' 1) What version of rubyripper are you using? On what operating system? -> rubyripper-git-20091128 on an uptodate Arch Linux 2) Are you using the gtk2 or the commandline interface? -> gtk2 3) Is the problem gone with the default settings? If so, please attach your settings file ($HOME/.rubyripper/settings). -> no 4) Does the problem only happen on a specific disc? If so, please attach the output of cdparanoia -Q. Also the freedb output would be nice if it may be related to it. -> Some work, some don't. here's one that doesn't work: cdparanoia III release 10.2 (September 11, 2008) Table of contents (audio tracks only): track length begin copy pre ch =========================================================== 1. 14119 [03:08.19] 0 [00:00.00] no no 2 2. 20224 [04:29.49] 14119 [03:08.19] no no 2 3. 24697 [05:29.22] 34343 [07:37.68] no no 2 4. 22450 [04:59.25] 59040 [13:07.15] no no 2 5. 21606 [04:48.06] 81490 [18:06.40] no no 2 6. 21354 [04:44.54] 103096 [22:54.46] no no 2 7. 30267 [06:43.42] 124450 [27:39.25] no no 2 8. 19965 [04:26.15] 154717 [34:22.67] no no 2 9. 20173 [04:28.73] 174682 [38:49.07] no no 2 10. 21850 [04:51.25] 194855 [43:18.05] no no 2 11. 21314 [04:44.14] 216705 [48:09.30] no no 2 TOTAL 238019 [52:53.44] (audio only) Please provide any additional information below. With Freedb MD Fetching disabled everything works Dec 10, 2009 issue 284 (Use Musicbrainz instead of FreeDB for tag lookup) commented on by oliver.g.charles - Hi, I work for MusicBrainz and I'd be interested in helping you guys get this in or submitting a patch. What type of functionality would you be looking it in RubyRipper? Hi, I work for MusicBrainz and I'd be interested in helping you guys get this in or submitting a patch. What type of functionality would you be looking it in RubyRipper? Dec 10, 2009 issue 357 (won't rip the disc if not found in freedb) commented on by oliver.g.charles - I get this too, and it's very frustrating I get this too, and it's very frustrating Dec 09, 2009 issue 371 (Last File Rip Reports "Filesize is not correct! Trying anoth...) commented on by Virusmater - same problem. i use TEAC DVD+RW DV-W58E with 685 offset same problem. i use TEAC DVD+RW DV-W58E with 685 offset Dec 09, 2009 issue 386 (Crash RubyRipper from git repo) reported by Virusmater - What steps will reproduce the problem? 1.Download RubyRipper from GitHub 2.Start ripping disc What is the expected output? What do you see instead? /home/kompot/src/rubyripper/rr_lib.rb:1472:in allFilter': undefined methodresponse_to?' for "/home/kompot/music/Marschak/2004 - Marschak":String (NoMethodError) from /home/kompot/src/rubyripper/rr_lib.rb:1447:in `fileFilter' from /home/kompot/src/rubyripper/rr_lib.rb:1299:in `giveDir' from /home/kompot/src/rubyripper/rr_lib.rb:1277:in `setDirectory' from /home/kompot/src/rubyripper/rr_lib.rb:1275:in `each' from /home/kompot/src/rubyripper/rr_lib.rb:1275:in `setDirectory' from /home/kompot/src/rubyripper/rr_lib.rb:1216:in `initialize' from /home/kompot/src/rubyripper/rr_lib.rb:2256:in `new' from /home/kompot/src/rubyripper/rr_lib.rb:2256:in `settingsOk' from ./rubyripper_cli.rb:424:in `prepareRip' from ./rubyripper_cli.rb:345:in `showFreedbOptions' from ./rubyripper_cli.rb:319:in `showFreedb' from ./rubyripper_cli.rb:287:in `handleFreedb' from ./rubyripper_cli.rb:266:in `get_cd_info' from ./rubyripper_cli.rb:49:in `initialize' from ./rubyripper_cli.rb:510:in `new' from ./rubyripper_cli.rb:510 1) What version of rubyripper are you using? On what operating system? -> 2) Are you using the gtk2 or the commandline interface? -> 3) Is the problem gone with the default settings? If so, please attach your settings file ($HOME/.rubyripper/settings). ->regardless 4) Does the problem only happen on a specific disc? If so, please attach the output of cdparanoia -Q. Also the freedb output would be nice if it may be related to it. ->cdparanoia III release 10.2 (September 11, 2008) Table of contents (audio tracks only): track length begin copy pre ch =========================================================== 1. 14841 [03:17.66] 0 [00:00.00] no no 2 2. 16683 [03:42.33] 14841 [03:17.66] no no 2 3. 14833 [03:17.58] 31524 [07:00.24] no no 2 4. 13864 [03:04.64] 46357 [10:18.07] no no 2 5. 14610 [03:14.60] 60221 [13:22.71] no no 2 6. 13150 [02:55.25] 74831 [16:37.56] no no 2 7. 20133 [04:28.33] 87981 [19:33.06] no no 2 8. 15022 [03:20.22] 108114 [24:01.39] no no 2 TOTAL 123136 [27:21.61] (audio only) What steps will reproduce the problem? 1.Download RubyRipper from GitHub 2.Start ripping disc What is the expected output? What do you see instead? /home/kompot/src/rubyripper/rr_lib.rb:1472:in allFilter': undefined methodresponse_to?' for "/home/kompot/music/Marschak/2004 - Marschak":String (NoMethodError) from /home/kompot/src/rubyripper/rr_lib.rb:1447:in `fileFilter' from /home/kompot/src/rubyripper/rr_lib.rb:1299:in `giveDir' from /home/kompot/src/rubyripper/rr_lib.rb:1277:in `setDirectory' from /home/kompot/src/rubyripper/rr_lib.rb:1275:in `each' from /home/kompot/src/rubyripper/rr_lib.rb:1275:in `setDirectory' from /home/kompot/src/rubyripper/rr_lib.rb:1216:in `initialize' from /home/kompot/src/rubyripper/rr_lib.rb:2256:in `new' from /home/kompot/src/rubyripper/rr_lib.rb:2256:in `settingsOk' from ./rubyripper_cli.rb:424:in `prepareRip' from ./rubyripper_cli.rb:345:in `showFreedbOptions' from ./rubyripper_cli.rb:319:in `showFreedb' from ./rubyripper_cli.rb:287:in `handleFreedb' from ./rubyripper_cli.rb:266:in `get_cd_info' from ./rubyripper_cli.rb:49:in `initialize' from ./rubyripper_cli.rb:510:in `new' from ./rubyripper_cli.rb:510 1) What version of rubyripper are you using? On what operating system? -> 2) Are you using the gtk2 or the commandline interface? -> 3) Is the problem gone with the default settings? If so, please attach your settings file ($HOME/.rubyripper/settings). ->regardless 4) Does the problem only happen on a specific disc? If so, please attach the output of cdparanoia -Q. Also the freedb output would be nice if it may be related to it. ->cdparanoia III release 10.2 (September 11, 2008) Table of contents (audio tracks only): track length begin copy pre ch =========================================================== 1. 14841 [03:17.66] 0 [00:00.00] no no 2 2. 16683 [03:42.33] 14841 [03:17.66] no no 2 3. 14833 [03:17.58] 31524 [07:00.24] no no 2 4. 13864 [03:04.64] 46357 [10:18.07] no no 2 5. 14610 [03:14.60] 60221 [13:22.71] no no 2 6. 13150 [02:55.25] 74831 [16:37.56] no no 2 7. 20133 [04:28.33] 87981 [19:33.06] no no 2 8. 15022 [03:20.22] 108114 [24:01.39] no no 2 TOTAL 123136 [27:21.61] (audio only) Older Dec 06, 2009 issue 383 (version0.5.7: cli interface broken ) commented on by execrable - I am getting this problem with 5.7 as well, although I can rip the disc just fine with the GUI. The cli just says that it can't find any cddb info about the cd, asks if i want to change configuration settings, then exits. I am getting this problem with 5.7 as well, although I can rip the disc just fine with the GUI. The cli just says that it can't find any cddb info about the cd, asks if i want to change configuration settings, then exits. Dec 06, 2009 issue 385 (When encoding to multiple formats not all tracks get encoded) commented on by hansonor...@verizon.net - I've switched to using the cli and this behavior does not occur when using the cli version of rubyripper. I've ripped and converted about 15 CDs now from cli and all have been perfect. I've switched to using the cli and this behavior does not occur when using the cli version of rubyripper. I've ripped and converted about 15 CDs now from cli and all have been perfect. Dec 05, 2009 issue 385 (When encoding to multiple formats not all tracks get encoded) reported by hansonor...@verizon.net - What steps will reproduce the problem? 1. Rip all CD tracks to flac, mp3, ogg and aac What is the expected output? What do you see instead? I expect all tracks to be encoded to the given format. I see a few tracks missing upon completion. Usually it's the first and last track on the CD, but sometimes tracks in between. 1) What version of rubyripper are you using? On what operating system? -> Rubyripper version 0.6.0b2 from git / Arch Linux - Linux desktop 2.6.31-ARCH #1 SMP PREEMPT Tue Nov 10 19:01:40 CET 2009 x86_64 AMD Athlon(tm) Dual Core Processor 4850e AuthenticAMD GNU/Linux with 4GB DDR2 800 RAM 2) Are you using the gtk2 or the commandline interface? -> gtk2 3) Is the problem gone with the default settings? If so, please attach your settings file ($HOME/.rubyripper/settings). -> Unknown. Settings attached. 4) Does the problem only happen on a specific disc? If so, please attach the output of cdparanoia -Q. Also the freedb output would be nice if it may be related to it. -> No, all discs Please provide any additional information below. Let me know if you have questions. What steps will reproduce the problem? 1. Rip all CD tracks to flac, mp3, ogg and aac What is the expected output? What do you see instead? I expect all tracks to be encoded to the given format. I see a few tracks missing upon completion. Usually it's the first and last track on the CD, but sometimes tracks in between. 1) What version of rubyripper are you using? On what operating system? -> Rubyripper version 0.6.0b2 from git / Arch Linux - Linux desktop 2.6.31-ARCH #1 SMP PREEMPT Tue Nov 10 19:01:40 CET 2009 x86_64 AMD Athlon(tm) Dual Core Processor 4850e AuthenticAMD GNU/Linux with 4GB DDR2 800 RAM 2) Are you using the gtk2 or the commandline interface? -> gtk2 3) Is the problem gone with the default settings? If so, please attach your settings file ($HOME/.rubyripper/settings). -> Unknown. Settings attached. 4) Does the problem only happen on a specific disc? If so, please attach the output of cdparanoia -Q. Also the freedb output would be nice if it may be related to it. -> No, all discs Please provide any additional information below. Let me know if you have questions. Dec 05, 2009 issue 384 (Tag issue: %a and %va switches place in "Other" on Various a...) commented on by Xenofil - Reading that thread it seems the way to go are to request native support of wavpack. Consider it done! :) And if it should get integrated, don't forget about wvgain for replaygaining (wavpack, wvunpack and wvgain are part of the same package in all distros). Until then I will have to reedit my commandline everytime I change between a various artist album and a single artist album it seems..... well, well... Reading that thread it seems the way to go are to request native support of wavpack. Consider it done! :) And if it should get integrated, don't forget about wvgain for replaygaining (wavpack, wvunpack and wvgain are part of the same package in all distros). Until then I will have to reedit my commandline everytime I change between a various artist album and a single artist album it seems..... well, well... Dec 05, 2009 issue 384 (Tag issue: %a and %va switches place in "Other" on Various a...) commented on by wizzim - I also reported this issue for "Other" : http://code.google.com/p/rubyripper/issues/detail?id=282 My 2 cents. I also reported this issue for "Other" : http://code.google.com/p/rubyripper/issues/detail?id=282 My 2 cents. Dec 01, 2009 issue 373 (Please add option to strip non-portable characters from file...) changed by boukewoudstra - Recently already two filename operations were added (lowercase and underscore instead of spaces). Since the code is already structured to support this kind of things, it is not too complicated to build. Last time this was requested this was different. Copying to fat32 formatted devices is an argument which I guess is valid for a lot of users. I do think all the filename and output dir config options have to move to a seperate tab though in the gtk2 interface. Status: Accepted Owner: boukewoudstra Recently already two filename operations were added (lowercase and underscore instead of spaces). Since the code is already structured to support this kind of things, it is not too complicated to build. Last time this was requested this was different. Copying to fat32 formatted devices is an argument which I guess is valid for a lot of users. I do think all the filename and output dir config options have to move to a seperate tab though in the gtk2 interface. Status: Accepted Owner: boukewoudstra Dec 01, 2009 issue 373 (Please add option to strip non-portable characters from file...) commented on by Xenofil - Yes, I absolutely see your point. However, a lot of users don't do much shell scripting (atleast concerning their music collection), and many users browse their music collection by filenames, not tags. Also I've understood that the rubyripper dev want's to keep complicated user configurable options to a minimum. So I don't think chars that might concern shell scripting should be converted in a mandatory fashion. However, those that affect transitions between filesystems might be considered such, as it might affect a broader user base, not all technically savvy. As such, as far as my investigation goes, those that are forbidden on fat32 covers those that are forbidden on other filesystems that are in use today (unless a lot of people use RT-11). Chars as 'newline' and 'null' should not be passed trough a freedb and rubyripper pipeline anyway, so I guess we can forget about such.... Yes, I absolutely see your point. However, a lot of users don't do much shell scripting (atleast concerning their music collection), and many users browse their music collection by filenames, not tags. Also I've understood that the rubyripper dev want's to keep complicated user configurable options to a minimum. So I don't think chars that might concern shell scripting should be converted in a mandatory fashion. However, those that affect transitions between filesystems might be considered such, as it might affect a broader user base, not all technically savvy. As such, as far as my investigation goes, those that are forbidden on fat32 covers those that are forbidden on other filesystems that are in use today (unless a lot of people use RT-11). Chars as 'newline' and 'null' should not be passed trough a freedb and rubyripper pipeline anyway, so I guess we can forget about such.... Dec 01, 2009 issue 371 (Last File Rip Reports "Filesize is not correct! Trying anoth...) commented on by ernst.blaauw - Same issue here. I have a DVDRAM GMA-4082N (from HL-DT-ST) with offset 667 and firmware HJ02. I'm using Rubyripper on Ubuntu Karmic from the PPA: https://launchpad.net/~aheck/+archive/ppa. $ apt-cache policy rubyripper rubyripper: Installed: 0.5.7-0ubuntu1~ppa4 Candidate: 0.5.7-0ubuntu1~ppa4 Version table: * 0.5.7-0ubuntu1~ppa4 0 500 http://ppa.launchpad.net karmic/main Packages 100 /var/lib/dpkg/status Same issue here. I have a DVDRAM GMA-4082N (from HL-DT-ST) with offset 667 and firmware HJ02. I'm using Rubyripper on Ubuntu Karmic from the PPA: https://launchpad.net/~aheck/+archive/ppa. $ apt-cache policy rubyripper rubyripper: Installed: 0.5.7-0ubuntu1~ppa4 Candidate: 0.5.7-0ubuntu1~ppa4 Version table: * 0.5.7-0ubuntu1~ppa4 0 500 http://ppa.launchpad.net karmic/main Packages 100 /var/lib/dpkg/status Nov 29, 2009 issue 373 (Please add option to strip non-portable characters from file...) commented on by ld.barthel - I probably do more shell scripting than the average user, so I do tend to be a bit more restrictive in naming files to eliminate that source of bugs. I do have a script that fixes these issues for me--I wrote it right after I discovered that rubyripper didn't include this functionality. It's an extra step for me, since this option was handled in grip, which I had used for years. Yes, adding this to rubyripper would require another option. Although you could make a case for at least excluding the MS-Windows illegal characters by default: audio files are frequently copied to portable devices which use fat32. I probably do more shell scripting than the average user, so I do tend to be a bit more restrictive in naming files to eliminate that source of bugs. I do have a script that fixes these issues for me--I wrote it right after I discovered that rubyripper didn't include this functionality. It's an extra step for me, since this option was handled in grip, which I had used for years. Yes, adding this to rubyripper would require another option. Although you could make a case for at least excluding the MS-Windows illegal characters by default: audio files are frequently copied to portable devices which use fat32. Nov 29, 2009 issue 373 (Please add option to strip non-portable characters from file...) commented on by Xenofil - I have personally only had problems with those chars that fat32 filesystem (rockbox on portable players) can't accept in filenames. I use the attached python script to change those chars to a underline char recursively from my ripping directory: `python fixnames.py' The unacceptable chars should be: \ / : * ? " < > \| The following you mention have never caused me trouble in the filenames of music files on any filesystem: [ ] ( ) { } & ' ! But those you can add to the python script if you so desire... If this should be added as a feature to rubyripper? Probably wouldn't hurt. But it should be optional then, meaning yet another tickbox. I have personally only had problems with those chars that fat32 filesystem (rockbox on portable players) can't accept in filenames. I use the attached python script to change those chars to a underline char recursively from my ripping directory: `python fixnames.py' The unacceptable chars should be: \ / : * ? " < > \| The following you mention have never caused me trouble in the filenames of music files on any filesystem: [ ] ( ) { } & ' ! But those you can add to the python script if you so desire... If this should be added as a feature to rubyripper? Probably wouldn't hurt. But it should be optional then, meaning yet another tickbox. Nov 28, 2009 issue 384 (Tag issue: %a and %va switches place in "Other" on Various a...) reported by Xenofil - rubyripper git 2009-11-27 on ubuntu x86, gtk interface. When ripping an album with "Various Artists" with "Vorbis" and "Other" encoding threads enabled, and the "mark disc as varous artists" checkbox ticked I get the ogg files tagged with ALBUM ARTIST as "Various Artists" and ARTIST set to the artist of the individual track, as I would have expected. But with the "Other" thread the result are opposite. This is my "Other" encoding parameters: wavpack -o "%o.wv" -w "Albumartist=%va" -w "Artist=%a" -w "Title=%t" -w "Album=%b" -w "Year=%y" -w "Track=%n" -w "Genre=%g" -hx3mt %i Here the "Artist" tag gets the value "Various Artists" and the name of the artist of the individual track end up in the "Albumartist" tag field. Ofcourse it's possible to workaround by switching place of %a and %va, but then I have to switch back before ripping any single artist album otherwise I get erroneous tagging of those. rubyripper git 2009-11-27 on ubuntu x86, gtk interface. When ripping an album with "Various Artists" with "Vorbis" and "Other" encoding threads enabled, and the "mark disc as varous artists" checkbox ticked I get the ogg files tagged with ALBUM ARTIST as "Various Artists" and ARTIST set to the artist of the individual track, as I would have expected. But with the "Other" thread the result are opposite. This is my "Other" encoding parameters: wavpack -o "%o.wv" -w "Albumartist=%va" -w "Artist=%a" -w "Title=%t" -w "Album=%b" -w "Year=%y" -w "Track=%n" -w "Genre=%g" -hx3mt %i Here the "Artist" tag gets the value "Various Artists" and the name of the artist of the individual track end up in the "Albumartist" tag field. Ofcourse it's possible to workaround by switching place of %a and %va, but then I have to switch back before ripping any single artist album otherwise I get erroneous tagging of those. Nov 27, 2009 issue 346 (Update translation for 0.6.0 release) commented on by goo...@JonnyJD.net - I reworked the german translation quite a bit. Several hundred lines. Changes in http://github.com/JonnyJD/rubyripper/commit/047d3457810916f211b002c2bd8072e1ec1cbb3e Complete file attached. I reworked the german translation quite a bit. Several hundred lines. Changes in http://github.com/JonnyJD/rubyripper/commit/047d3457810916f211b002c2bd8072e1ec1cbb3e Complete file attached. Nov 27, 2009 issue 309 (Allow mp3gain to be used without altering audio data) changed by boukewoudstra - Status: Accepted Owner: boukewoudstra Status: Accepted Owner: boukewoudstra Nov 26, 2009 issue 309 (Allow mp3gain to be used without altering audio data) commented on by goo...@JonnyJD.net - I will also use the feature of having mp3gain not to change the audio frames. I made a commit in my fork for this and also attach a patch for others to use. http://github.com/JonnyJD/rubyripper/commit/bd61b144df428851acfe99e1862002203b936069 With this change you can set gainTagsOnly=true in order for mp3gain to write tags only (and don't do anything with wavgain). The default is false, because that is what happens now. Amarok 2.1 understands APEv2 tags now with taglib and so does foobar. If you still need ID3v2: recent versions of mp3gain have an option "-s i", writing ID3v2 tags. PS: I use mp3 because I can play that everywhere. I also tested the quality a lot and it was still better than vorbis (vorbis had some issues with electronic music). However, I also rip to flac for my archive. I will also use the feature of having mp3gain not to change the audio frames. I made a commit in my fork for this and also attach a patch for others to use. http://github.com/JonnyJD/rubyripper/commit/bd61b144df428851acfe99e1862002203b936069 With this change you can set gainTagsOnly=true in order for mp3gain to write tags only (and don't do anything with wavgain). The default is false, because that is what happens now. Amarok 2.1 understands APEv2 tags now with taglib and so does foobar. If you still need ID3v2: recent versions of mp3gain have an option "-s i", writing ID3v2 tags. PS: I use mp3 because I can play that everywhere. I also tested the quality a lot and it was still better than vorbis (vorbis had some issues with electronic music). However, I also rip to flac for my archive. Nov 26, 2009 issue 383 (version0.5.7: cli interface broken ) commented on by spe...@gmail.com - I tried only a disc, but please read that I wrote that rubyripper version 0.5.5 does not have any single problem ripping it; that's the reason why I didn't tested other discs. The rip with the 0.5.5 version of ruby ripper worked perfectly; and I listened to it just today from the beginning to the end. I have the feel that it's just a matter of user interface. Uhm, idea. Is it possible that RR 0.5.7, founding a config file of 0.5.5 does some mess with it and thus behave in an unpredictable way? I tried only a disc, but please read that I wrote that rubyripper version 0.5.5 does not have any single problem ripping it; that's the reason why I didn't tested other discs. The rip with the 0.5.5 version of ruby ripper worked perfectly; and I listened to it just today from the beginning to the end. I have the feel that it's just a matter of user interface. Uhm, idea. Is it possible that RR 0.5.7, founding a config file of 0.5.5 does some mess with it and thus behave in an unpredictable way? Nov 26, 2009 issue 383 (version0.5.7: cli interface broken ) commented on by goo...@JonnyJD.net - Did you try different CDs and tried the same CDs for both versions? Did you check that you have the correct CD drive listed in the settings shown? I also have a disc where rubyripper just exits, but other CDs work fine. (It is a disc with some very weird copy protection, which doesn't work with cdparanoia anyways) Did you try different CDs and tried the same CDs for both versions? Did you check that you have the correct CD drive listed in the settings shown? I also have a disc where rubyripper just exits, but other CDs work fine. (It is a disc with some very weird copy protection, which doesn't work with cdparanoia anyways) Nov 25, 2009 issue 383 (version0.5.7: cli interface broken ) reported by spe...@gmail.com - What steps will reproduce the problem? 1. Execute ./rubyripper_cli.rb 2. Go on with the settings 3. It will exit without ripping anything. Version 0.5.5 works just fine. Same machine. Version 0.5.7 don't. Please contact me for any further info you can need. Thanks What steps will reproduce the problem? 1. Execute ./rubyripper_cli.rb 2. Go on with the settings 3. It will exit without ripping anything. Version 0.5.5 works just fine. Same machine. Version 0.5.7 don't. Please contact me for any further info you can need. Thanks Nov 25, 2009 issue 382 (reading entries in ~/.cddb: handleResponse: undefined method...) reported by goo...@JonnyJD.net - What steps will reproduce the problem? 1. generate a ~/.cddb entry for a disc (amarok made this for me I think) 2. try to rip the same disc with rubyripper rr finds that ~/.cddb entry and tries to use it, but fails and crashes. $ LC_ALL=C rrip_cli Use config file ~/.rubyripper/settings Audio-disc found, number of tracks : 12, total playlength : 52:21 Fetching freedb info... Local file found /home/jonnyjd/.cddb/reggae/aa11560d /usr/lib/ruby/site_ruby/1.9.1/rr_lib.rb:1103:in `handleResponse': undefined method `each' for #<String:0x000000014887e8> (NoMethodError) from /usr/lib/ruby/site_ruby/1.9.1/rr_lib.rb:961:in `searchMetadata' from /usr/lib/ruby/site_ruby/1.9.1/rr_lib.rb:940:in `freedb' from /usr/bin/rrip_cli:279:in `handleFreedb' from /usr/bin/rrip_cli:266:in `get_cd_info' from /usr/bin/rrip_cli:49:in `initialize' from /usr/bin/rrip_cli:510:in `new' from /usr/bin/rrip_cli:510:in `<main>' 1) What version of rubyripper are you using? On what operating system? -> latest git from today 2) Are you using the gtk2 or the commandline interface? -> cli This happens with every type of disc I tried. It has nothing to do with UTF, locale or hidden tracks. rm -r ~/.cddb solves this issue as a workaround What steps will reproduce the problem? 1. generate a ~/.cddb entry for a disc (amarok made this for me I think) 2. try to rip the same disc with rubyripper rr finds that ~/.cddb entry and tries to use it, but fails and crashes. $ LC_ALL=C rrip_cli Use config file ~/.rubyripper/settings Audio-disc found, number of tracks : 12, total playlength : 52:21 Fetching freedb info... Local file found /home/jonnyjd/.cddb/reggae/aa11560d /usr/lib/ruby/site_ruby/1.9.1/rr_lib.rb:1103:in `handleResponse': undefined method `each' for #<String:0x000000014887e8> (NoMethodError) from /usr/lib/ruby/site_ruby/1.9.1/rr_lib.rb:961:in `searchMetadata' from /usr/lib/ruby/site_ruby/1.9.1/rr_lib.rb:940:in `freedb' from /usr/bin/rrip_cli:279:in `handleFreedb' from /usr/bin/rrip_cli:266:in `get_cd_info' from /usr/bin/rrip_cli:49:in `initialize' from /usr/bin/rrip_cli:510:in `new' from /usr/bin/rrip_cli:510:in `<main>' 1) What version of rubyripper are you using? On what operating system? -> latest git from today 2) Are you using the gtk2 or the commandline interface? -> cli This happens with every type of disc I tried. It has nothing to do with UTF, locale or hidden tracks. rm -r ~/.cddb solves this issue as a workaround Nov 25, 2009 issue 381 (can't modify frozen string on disc with hidden track and wit...) commented on by goo...@JonnyJD.net - With that repo you can pull the changes, with the patches I send before you can include the changes with "git am <patch>" Please tell me a patch file is still more convenient and if I need to include some details in the summary so you can pull it without having to make more changes. With that repo you can pull the changes, with the patches I send before you can include the changes with "git am <patch>" Please tell me a patch file is still more convenient and if I need to include some details in the summary so you can pull it without having to make more changes. Nov 25, 2009 issue 381 (can't modify frozen string on disc with hidden track and wit...) commented on by goo...@JonnyJD.net - My solution is to duplicate the localised strings for hidden tracks in order to be able to change them: http://github.com/JonnyJD/rubyripper/commit/fe63d2c7f04fe05d26f60174e761e89e3dcaa866 (This time I made it in a github repo. I will send a pull request) The other solution would have been to check if a string is frozen before making changes. Just checking for force_encoding would be wrong, because this would introduce the substitution bug again. And if we test in tagFilter, we might run into problems with weird localisation. Additionally: If we want to encode in latin for lame, then we also need to modify these strings. Finally, I think unfreezing these strings is the best solution. My solution is to duplicate the localised strings for hidden tracks in order to be able to change them: http://github.com/JonnyJD/rubyripper/commit/fe63d2c7f04fe05d26f60174e761e89e3dcaa866 (This time I made it in a github repo. I will send a pull request) The other solution would have been to check if a string is frozen before making changes. Just checking for force_encoding would be wrong, because this would introduce the substitution bug again. And if we test in tagFilter, we might run into problems with weird localisation. Additionally: If we want to encode in latin for lame, then we also need to modify these strings. Finally, I think unfreezing these strings is the best solution. Nov 25, 2009 issue 381 (can't modify frozen string on disc with hidden track and wit...) commented on by goo...@JonnyJD.net - I think I found the reason why LC_ALL=C fixes the issue. "Unknown Artist" is "Unbekannter Künstler" in german. So this is the point where non-ascii characters are introduced to this release. This string is not used, since it is no various artist release, but it still runs through certain modifications, I guess. That Force_encoding has no problem for fixed strings if they are already ASCII, but it does when they are in latin or UTF. It somehow looks like we have to extend that encoding hack even further.. I think I found the reason why LC_ALL=C fixes the issue. "Unknown Artist" is "Unbekannter Künstler" in german. So this is the point where non-ascii characters are introduced to this release. This string is not used, since it is no various artist release, but it still runs through certain modifications, I guess. That Force_encoding has no problem for fixed strings if they are already ASCII, but it does when they are in latin or UTF. It somehow looks like we have to extend that encoding hack even further.. Nov 25, 2009 issue 381 (can't modify frozen string on disc with hidden track and wit...) reported by goo...@JonnyJD.net - What steps will reproduce the problem? 1. insert a disc with a hidden pregap track 2. LANG=de_DE.UTF-8 rrip_cli What is the expected output? What do you see instead? I expect the cdrdao analysis to start, but I get: /usr/lib/ruby/site_ruby/1.9.1/rr_lib.rb:1475:in `force_encoding': can't modify frozen string (RuntimeError) from /usr/lib/ruby/site_ruby/1.9.1/rr_lib.rb:1475:in `allFilter' from /usr/lib/ruby/site_ruby/1.9.1/rr_lib.rb:1456:in `tagFilter' from /usr/lib/ruby/site_ruby/1.9.1/rr_lib.rb:1434:in `setHiddenTrack' from /usr/lib/ruby/site_ruby/1.9.1/rr_lib.rb:1389:in `setFileNames' from /usr/lib/ruby/site_ruby/1.9.1/rr_lib.rb:1310:in `attemptDirCreation' from /usr/lib/ruby/site_ruby/1.9.1/rr_lib.rb:1505:in `overwriteDir' from /usr/lib/ruby/site_ruby/1.9.1/rr_lib.rb:2375:in `overwriteDir' from /usr/bin/rrip_cli:442:in `dir_exists' from /usr/bin/rrip_cli:469:in `update' from /usr/bin/rrip_cli:428:in `prepareRip' from /usr/bin/rrip_cli:345:in `showFreedbOptions' from /usr/bin/rrip_cli:319:in `showFreedb' from /usr/bin/rrip_cli:287:in `handleFreedb' from /usr/bin/rrip_cli:266:in `get_cd_info' from /usr/bin/rrip_cli:49:in `initialize' from /usr/bin/rrip_cli:510:in `new' from /usr/bin/rrip_cli:510:in `<main>' 1) What version of rubyripper are you using? On what operating system? -> git 2) Are you using the gtk2 or the commandline interface? -> rr_cli 3) Is the problem gone with the default settings? If so, please attach your settings file ($HOME/.rubyripper/settings). -> 4) Does the problem only happen on a specific disc? If so, please attach the output of cdparanoia -Q. Also the freedb output would be nice if it may be related to it. -> anything with a pregap track Please provide any additional information below. There is no issue when I do LC_ALL=C rr_cli This is quite strange, because there are only ASCII name on the whole release. I will try to test and check a bit more later on. I used this release: Rammstein - Reise, Reise This has something to do with using a fixed name for the hidden track, obviously. What steps will reproduce the problem? 1. insert a disc with a hidden pregap track 2. LANG=de_DE.UTF-8 rrip_cli What is the expected output? What do you see instead? I expect the cdrdao analysis to start, but I get: /usr/lib/ruby/site_ruby/1.9.1/rr_lib.rb:1475:in `force_encoding': can't modify frozen string (RuntimeError) from /usr/lib/ruby/site_ruby/1.9.1/rr_lib.rb:1475:in `allFilter' from /usr/lib/ruby/site_ruby/1.9.1/rr_lib.rb:1456:in `tagFilter' from /usr/lib/ruby/site_ruby/1.9.1/rr_lib.rb:1434:in `setHiddenTrack' from /usr/lib/ruby/site_ruby/1.9.1/rr_lib.rb:1389:in `setFileNames' from /usr/lib/ruby/site_ruby/1.9.1/rr_lib.rb:1310:in `attemptDirCreation' from /usr/lib/ruby/site_ruby/1.9.1/rr_lib.rb:1505:in `overwriteDir' from /usr/lib/ruby/site_ruby/1.9.1/rr_lib.rb:2375:in `overwriteDir' from /usr/bin/rrip_cli:442:in `dir_exists' from /usr/bin/rrip_cli:469:in `update' from /usr/bin/rrip_cli:428:in `prepareRip' from /usr/bin/rrip_cli:345:in `showFreedbOptions' from /usr/bin/rrip_cli:319:in `showFreedb' from /usr/bin/rrip_cli:287:in `handleFreedb' from /usr/bin/rrip_cli:266:in `get_cd_info' from /usr/bin/rrip_cli:49:in `initialize' from /usr/bin/rrip_cli:510:in `new' from /usr/bin/rrip_cli:510:in `<main>' 1) What version of rubyripper are you using? On what operating system? -> git 2) Are you using the gtk2 or the commandline interface? -> rr_cli 3) Is the problem gone with the default settings? If so, please attach your settings file ($HOME/.rubyripper/settings). -> 4) Does the problem only happen on a specific disc? If so, please attach the output of cdparanoia -Q. Also the freedb output would be nice if it may be related to it. -> anything with a pregap track Please provide any additional information below. There is no issue when I do LC_ALL=C rr_cli This is quite strange, because there are only ASCII name on the whole release. I will try to test and check a bit more later on. I used this release: Rammstein - Reise, Reise This has something to do with using a fixed name for the hidden track, obviously. Nov 25, 2009 issue 375 (Faster ripping possible?) commented on by goo...@JonnyJD.net - try adding "-Z" to the cdparanoia options. Encoding is only the slow part if you have old hardware. What normally takes time is the ripping. "-Z" disables verification and correction in cdparanoia. The check rubyripper is doing is still in place. try adding "-Z" to the cdparanoia options. Encoding is only the slow part if you have old hardware. What normally takes time is the ripping. "-Z" disables verification and correction in cdparanoia. The check rubyripper is doing is still in place. Nov 25, 2009 issue 380 (Rubyripper always wants to overwrite directories) reported by bryansbooking - What steps will reproduce the problem? 1.Set the base directory in "Preferences->Other" to NOT include a filenaming scheme parameter (ie %b, %a, etc.) 2.Rip a CD 3.Rubyripper will ask if overwriting an already existant directory is desired What is the expected output? What do you see instead? Ideally the program will have the capability to add new ripped files to an existing directory. Some of us like to keep all or most of our music in the same general directory. 1) What version of rubyripper are you using? On what operating system? ->0.5.7, on Ubuntu 9.10 standard install, i386 2) Are you using the gtk2 or the commandline interface? ->gtk2 3) Is the problem gone with the default settings? If so, please attach your settings file ($HOME/.rubyripper/settings). ->no 4) Does the problem only happen on a specific disc? If so, please attach the output of cdparanoia -Q. Also the freedb output would be nice if it may be related to it. ->no Please provide any additional information below. This is probably more a feature request than a bug per se, since the workaround is just to include a unique directory name inducing set of parameters (%a/%b works nicely), but still. The program is a bit aggressive about its directories. What steps will reproduce the problem? 1.Set the base directory in "Preferences->Other" to NOT include a filenaming scheme parameter (ie %b, %a, etc.) 2.Rip a CD 3.Rubyripper will ask if overwriting an already existant directory is desired What is the expected output? What do you see instead? Ideally the program will have the capability to add new ripped files to an existing directory. Some of us like to keep all or most of our music in the same general directory. 1) What version of rubyripper are you using? On what operating system? ->0.5.7, on Ubuntu 9.10 standard install, i386 2) Are you using the gtk2 or the commandline interface? ->gtk2 3) Is the problem gone with the default settings? If so, please attach your settings file ($HOME/.rubyripper/settings). ->no 4) Does the problem only happen on a specific disc? If so, please attach the output of cdparanoia -Q. Also the freedb output would be nice if it may be related to it. ->no Please provide any additional information below. This is probably more a feature request than a bug per se, since the workaround is just to include a unique directory name inducing set of parameters (%a/%b works nicely), but still. The program is a bit aggressive about its directories. Nov 24, 2009 issue 379 ([PATCH 1/1] Typo. s/exist/exists/) commented on by boukewoudstra - For simple patches like this I don't mind :). I usually edit it by hand. Previous patches were easily applied as well. But if you're concerned with merging your changes easy, you should clone the project and ask me to pull your changes ;) But if that's too much, the patches are just fine. For simple patches like this I don't mind :). I usually edit it by hand. Previous patches were easily applied as well. But if you're concerned with merging your changes easy, you should clone the project and ask me to pull your changes ;) But if that's too much, the patches are just fine. Nov 24, 2009 issue 375 (Faster ripping possible?) Status changed by boukewoudstra - Status: New Status: New Nov 24, 2009 issue 379 ([PATCH 1/1] Typo. s/exist/exists/) commented on by pm.debian - Thank you. Should I format my patch next time differently so that you can apply it directly? Thank you. Should I format my patch next time differently so that you can apply it directly? Nov 24, 2009 issue 375 (Faster ripping possible?) commented on by pm.debian - > Please look into your $HOME/.rubyripper/settings file. There is maxThreads=5 written. > I suspect your threads are being reset to zero because of this piece of code: […] No, it should not be since I have the required libraries installed. $ dpkg -l libgtk2-ruby libgtk2-ruby 0.19.3-1 > Please look into your $HOME/.rubyripper/settings file. There is maxThreads=5 written. > I suspect your threads are being reset to zero because of this piece of code: […] No, it should not be since I have the required libraries installed. $ dpkg -l libgtk2-ruby libgtk2-ruby 0.19.3-1 Nov 24, 2009 issue 378 (Where are my posts?) changed by boukewoudstra - I guess you already found out, seeing your second comment. Status: Fixed Owner: boukewoudstra I guess you already found out, seeing your second comment. Status: Fixed Owner: boukewoudstra Nov 24, 2009 issue 379 ([PATCH 1/1] Typo. s/exist/exists/) changed by boukewoudstra - Fixed with commit: http://github.com/rubyripperdev/rubyripper/commit/da09172495f300ba0106e89a9f71c3ed8829c0bc Status: Fixed Owner: boukewoudstra Fixed with commit: http://github.com/rubyripperdev/rubyripper/commit/da09172495f300ba0106e89a9f71c3ed8829c0bc Status: Fixed Owner: boukewoudstra Nov 24, 2009 issue 375 (Faster ripping possible?) commented on by boukewoudstra - Please look into your $HOME/.rubyripper/settings file. I suspect your threads are being reset to zero because of this piece of code: if Gtk::BINDING_VERSION[1] < 18 && @settings['maxThreads'] > 0 @settings['maxThreads'] = 0 puts "WARNING: Threads are not supported on ruby gtk2-bindings" puts "that are older than 0.18.0. Setting them to zero." puts "Please upgrade your bindings if you want threads." end Please look into your $HOME/.rubyripper/settings file. I suspect your threads are being reset to zero because of this piece of code: if Gtk::BINDING_VERSION[1] < 18 && @settings['maxThreads'] > 0 @settings['maxThreads'] = 0 puts "WARNING: Threads are not supported on ruby gtk2-bindings" puts "that are older than 0.18.0. Setting them to zero." puts "Please upgrade your bindings if you want threads." end Nov 24, 2009 issue 375 (Faster ripping possible?) commented on by pm.debian - Sorry. It does not work for me. I entered »5« as the number for encoding threads. I do not see a difference. `top` shows me the same resource usage as before and the tracks are read from CD only after the one before has been encoded and compared. I see the following in the logs. Adding track 1 (flac) into the waitingroom.. WARNING: Normalize is not installed. Cannot normalize files > Note: This message is strange, since I disabled to normalize the tracks. But this is for another ticket. Inside handleThreads: maxthreads = 5, threads = 0 Can someone enlighten me, what I am doing wrong? Sorry. It does not work for me. I entered »5« as the number for encoding threads. I do not see a difference. `top` shows me the same resource usage as before and the tracks are read from CD only after the one before has been encoded and compared. I see the following in the logs. Adding track 1 (flac) into the waitingroom.. WARNING: Normalize is not installed. Cannot normalize files > Note: This message is strange, since I disabled to normalize the tracks. But this is for another ticket. Inside handleThreads: maxthreads = 5, threads = 0 Can someone enlighten me, what I am doing wrong?

issue 386 (Crash RubyRipper from git repo) reported by Virusmater - What steps will reproduce the problem? 1.Download RubyRipper from GitHub 2.Start ripping disc What is the expected output? What do you see instead? /home/kompot/src/rubyripper/rr_lib.rb:1472:in allFilter': undefined methodresponse_to?' for "/home/kompot/music/Marschak/2004 - Marschak":String (NoMethodError) from /home/kompot/src/rubyripper/rr_lib.rb:1447:in `fileFilter' from /home/kompot/src/rubyripper/rr_lib.rb:1299:in `giveDir' from /home/kompot/src/rubyripper/rr_lib.rb:1277:in `setDirectory' from /home/kompot/src/rubyripper/rr_lib.rb:1275:in `each' from /home/kompot/src/rubyripper/rr_lib.rb:1275:in `setDirectory' from /home/kompot/src/rubyripper/rr_lib.rb:1216:in `initialize' from /home/kompot/src/rubyripper/rr_lib.rb:2256:in `new' from /home/kompot/src/rubyripper/rr_lib.rb:2256:in `settingsOk' from ./rubyripper_cli.rb:424:in `prepareRip' from ./rubyripper_cli.rb:345:in `showFreedbOptions' from ./rubyripper_cli.rb:319:in `showFreedb' from ./rubyripper_cli.rb:287:in `handleFreedb' from ./rubyripper_cli.rb:266:in `get_cd_info' from ./rubyripper_cli.rb:49:in `initialize' from ./rubyripper_cli.rb:510:in `new' from ./rubyripper_cli.rb:510 1) What version of rubyripper are you using? On what operating system? -> 2) Are you using the gtk2 or the commandline interface? -> 3) Is the problem gone with the default settings? If so, please attach your settings file ($HOME/.rubyripper/settings). ->regardless 4) Does the problem only happen on a specific disc? If so, please attach the output of cdparanoia -Q. Also the freedb output would be nice if it may be related to it. ->cdparanoia III release 10.2 (September 11, 2008) Table of contents (audio tracks only): track length begin copy pre ch =========================================================== 1. 14841 [03:17.66] 0 [00:00.00] no no 2 2. 16683 [03:42.33] 14841 [03:17.66] no no 2 3. 14833 [03:17.58] 31524 [07:00.24] no no 2 4. 13864 [03:04.64] 46357 [10:18.07] no no 2 5. 14610 [03:14.60] 60221 [13:22.71] no no 2 6. 13150 [02:55.25] 74831 [16:37.56] no no 2 7. 20133 [04:28.33] 87981 [19:33.06] no no 2 8. 15022 [03:20.22] 108114 [24:01.39] no no 2 TOTAL 123136 [27:21.61] (audio only)

What steps will reproduce the problem? 1.Download RubyRipper from GitHub 2.Start ripping disc What is the expected output? What do you see instead? /home/kompot/src/rubyripper/rr_lib.rb:1472:in allFilter': undefined methodresponse_to?' for "/home/kompot/music/Marschak/2004 - Marschak":String (NoMethodError) from /home/kompot/src/rubyripper/rr_lib.rb:1447:in `fileFilter' from /home/kompot/src/rubyripper/rr_lib.rb:1299:in `giveDir' from /home/kompot/src/rubyripper/rr_lib.rb:1277:in `setDirectory' from /home/kompot/src/rubyripper/rr_lib.rb:1275:in `each' from /home/kompot/src/rubyripper/rr_lib.rb:1275:in `setDirectory' from /home/kompot/src/rubyripper/rr_lib.rb:1216:in `initialize' from /home/kompot/src/rubyripper/rr_lib.rb:2256:in `new' from /home/kompot/src/rubyripper/rr_lib.rb:2256:in `settingsOk' from ./rubyripper_cli.rb:424:in `prepareRip' from ./rubyripper_cli.rb:345:in `showFreedbOptions' from ./rubyripper_cli.rb:319:in `showFreedb' from ./rubyripper_cli.rb:287:in `handleFreedb' from ./rubyripper_cli.rb:266:in `get_cd_info' from ./rubyripper_cli.rb:49:in `initialize' from ./rubyripper_cli.rb:510:in `new' from ./rubyripper_cli.rb:510 1) What version of rubyripper are you using? On what operating system? -> 2) Are you using the gtk2 or the commandline interface? -> 3) Is the problem gone with the default settings? If so, please attach your settings file ($HOME/.rubyripper/settings). ->regardless 4) Does the problem only happen on a specific disc? If so, please attach the output of cdparanoia -Q. Also the freedb output would be nice if it may be related to it. ->cdparanoia III release 10.2 (September 11, 2008) Table of contents (audio tracks only): track length begin copy pre ch =========================================================== 1. 14841 [03:17.66] 0 [00:00.00] no no 2 2. 16683 [03:42.33] 14841 [03:17.66] no no 2 3. 14833 [03:17.58] 31524 [07:00.24] no no 2 4. 13864 [03:04.64] 46357 [10:18.07] no no 2 5. 14610 [03:14.60] 60221 [13:22.71] no no 2 6. 13150 [02:55.25] 74831 [16:37.56] no no 2 7. 20133 [04:28.33] 87981 [19:33.06] no no 2 8. 15022 [03:20.22] 108114 [24:01.39] no no 2 TOTAL 123136 [27:21.61] (audio only)

Yesterday

Last 7 days

Last 30 days

Older