Please revive this project

[GoogleCodeExporter]

Hello,

I'm mainly reporting this as an issue because I'd like to see another release 
of this Project on my Ubuntu 12.04 LTS so I can continue to rip my CDs 
accurately using your software.  I'd be happy to test anything you have and 
provide logs for the testing if you were to rebuild this and add on to it.

Sincerest, Alex

Original issue reported on code.google.com by justlike...@gmail.com on 20 Sep 2012 at 3:23

[GoogleCodeExporter]

Thanks for the heads up :).

Now my studies are finished and holidays are over, there really aren't any 
major problems to continue this project. Guess I need some rhythm to start 
again. Let's try the following, for coming weeks I am planning the thursday 
night to work on this project again. I will use this issue to report any 
progress.

Original comment by boukewou...@gmail.com on 20 Sep 2012 at 6:16

[GoogleCodeExporter]

Ok, so not this week.

Had to do my duties as the chess youth leader:
* send the invitations for the school chess tournament in november
* make a summary of our meeting as youth trainers last week
* send an up-to-date list of our youth players for the financial administration
* set up our tournament for our youth players.

Next week should be better, it's a recurring event in my agenda at least.

Original comment by boukewou...@gmail.com on 20 Sep 2012 at 6:59

[GoogleCodeExporter]

Hey, not a problem, I'm happy I could get your momentum starting again. This is 
a great program/application - I use it over anything else to rip my CDs in 
exact, precise condition.

Original comment by justlike...@gmail.com on 20 Sep 2012 at 11:01

[GoogleCodeExporter]

Indeed. This project needs to pick up steam. 

Original comment by perry...@gmail.com on 27 Sep 2012 at 2:50

[GoogleCodeExporter]

The cuesheet saving for image rips is working again after commit: 
http://code.google.com/p/rubyripper/source/detail?r=317b78196c1b1d95692b0373708e
5d687f9f9710

I have some worries about the performance though in comparing the files. It 
takes too long and the application even freezes after the rip when trying to 
close it.

Original comment by boukewou...@gmail.com on 27 Sep 2012 at 7:42

[GoogleCodeExporter]

Added support for the opus codec in the backend since this was easy to do:
http://code.google.com/p/rubyripper/source/detail?r=148f1a1803120c649fa61387a84b
dd1e8154db8a

Original comment by boukewou...@gmail.com on 27 Sep 2012 at 8:32

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Can't promise that every week will be so productive as this one ;)

* Did some debugging and cleaning of several open issues.
* Added support for the opus codec in commandline and gtk2 interfaces.
* Redesign of codec selection in the gtk2 interface, so it takes less space.
* Fixed a problem with other locales in some corner cases (also on stable 
branch).
* Started working on cuesheet generation for track based ripping.

Plan is to continue working on the cuesheet generation. I have to make sure the 
options for the cuesheet are actually enforced in the ripping process.

Original comment by boukewou...@gmail.com on 4 Oct 2012 at 7:06

[GoogleCodeExporter]

So not this week, my sister invited me over to make some traditional Dutch 
meal. She had some nice friends coming over from Hong Kong doing a trip in 
Europe. I made some nice "Boerenkool met worst". Everybody agreed this tasted 
delicious.

Original comment by boukewou...@gmail.com on 11 Oct 2012 at 9:57

[GoogleCodeExporter]

No worries mate, take your time, enjoy it, Lots of people DO want to see
this project revived, but DO it on your own time, whenever you can :)

Original comment by justlike...@gmail.com on 12 Oct 2012 at 8:29

[GoogleCodeExporter]

I second for revival of this project. Rubyripper rocks! :)

Original comment by kimmon.l...@gmail.com on 16 Oct 2012 at 9:33

[GoogleCodeExporter]

Oops, forgot to give an update last thursday. Well, a busy week again. Been to 
the "Doe maar" concert in middle of the week and helped my sisters boyfriend 
from Brazil with his Dutch.

But tonight I found some time, maybe tomorrow as wel. Results for today:

Fixed the problem with not saving empty strings (actually not loading them).
Fixed the problem (probably) with importing iso-8859-1 metadata from freedb.

Original comment by boukewou...@gmail.com on 20 Oct 2012 at 7:36

[GoogleCodeExporter]

For the next release it would be great if you could include the eac style logs. 
And the logo i sent you in the past (if you like it that is).

Rubyripper is the best tool we have right now for linux ripping and few more 
tweaks will make it better.

Original comment by barz...@gmail.com on 23 Oct 2012 at 9:18

[GoogleCodeExporter]

A lot is done this week:
* fixed the cuesheet generation for discs when appending gaps
* fix crash with cuesheet if not all tracks are selected
* added the ISRC code to the cuesheet
* change default gap method to appending (like EAC)

Also closed or analyzed a lot of different issues.

Can't promise so much for the rest of the week. Tomorrow Dutch lessons with 
Lucas again; Friday there is a "bokbier" festival at Amsterdam, Saturday I have 
a horror event with some friends (Cabin in the Woods, The Hills have Eyes, Rec 
3, Helloween) and I guess sunday I'll need some rest.

Original comment by boukewou...@gmail.com on 24 Oct 2012 at 10:16

[GoogleCodeExporter]

Did some analysis on the performance of trials. Which clearly showed that 
calculating the peak level is taking about 95% of all time. You can see for 
yourself with latest git when debug is enabled in preferences.

Original comment by boukewou...@gmail.com on 1 Nov 2012 at 8:27

[GoogleCodeExporter]

Just to let you know that there are people out there really wanting to see your 
project go forward. We all appreciate your great work from the very beginning. 
I would hate to see this project fade away. Ripping CDs is important. Who wants 
to buy inferior quality mp3s that you really never own? I personally would be 
happy to donate some money (because I'm in a position to), like buying the 
sofware in the commercial world. You should think about setting up a donation/ 
paypal account to compensate you for your time and to help you develop it 
further, if that's in your plans.

Original comment by martin.c...@gmail.com on 10 Nov 2012 at 1:24

[GoogleCodeExporter]

@Martin; I already earn money on my fulltime job, so this is not a problem. 
Helping with testing and giving feedback (especially compliments :P) helps 
better.

Just noticed I forgot to give an update this week. I did some work moving the 
hash calculation out of the securerip class. The Secure rip class is one of the 
most complex pieces of code, so it's responsibilities should be stripped as 
much as possible.

The problem with peak calculation processing time remains. I searched for disks 
that don't have a peak volume of 100%, haven't found one so far. If the peak is 
say 80%, this means that the music volume can be raised till 100%. The 16-bit 
format that is used on audio discs have a maximum of 96 decibel. For ripping 
means the peak volume is only important if it stays at 0%. This indicates that 
the ripping went wrong.

For alternatives to calculate peak volume I found "sox" to be a possible 
alternative.  The command 'sox "trackname.wav" -n stats' gives some info about 
the discs, including peak values. I haven't found out how to map this info to 
the peak volume we're showing yet. Any help / examples are appreciated.

Original comment by boukewou...@gmail.com on 10 Nov 2012 at 1:41

[GoogleCodeExporter]

Since there were no complaints for my plan to use sox I just tried to implement 
it. If sox is not found on your system it will fall back to the manual 
calculation.

Using sox proves however to be much faster. I think I can safely say that the 
ripping process is twice as fast now. There are two reasons for this; it 
reduces the time calculating the peak value. A nice side effect is that the 
disc can come up to speed for ripping.

Original comment by boukewou...@gmail.com on 15 Nov 2012 at 8:34

[GoogleCodeExporter]

Not much progress to report. There were two reasons for this:
* I bought my first house; so arrangements with the broker and my financial 
advisor. Also a lot of reading in the different options and the contract I had 
to sign.
* I arranged the chess tournament for local schools. It all went fine today.

Original comment by boukewou...@gmail.com on 22 Nov 2012 at 7:11

[GoogleCodeExporter]

No worries man.

Original comment by justlike...@gmail.com on 22 Nov 2012 at 11:22

[GoogleCodeExporter]

Moving the updates to wednesday, for thursday I'll do some ice skating, yeah :).

I looked at the musicbrainz code to find out why it was not working. I found 
the problem, for the solution I am hoping for Ian to bring some life into it 
again. He did all the work for the musicbrainz code in the first place.

Original comment by boukewou...@gmail.com on 28 Nov 2012 at 8:46

[GoogleCodeExporter]

I fixed the musicbrainz problem myself and in the process cleaned up the code 
as well. Rubyripper is getting in a quite reasonable shape now. I would like to 
identify the work that has to be done before publishing an official beta 
release. Any input is welcome.

Original comment by boukewou...@gmail.com on 6 Dec 2012 at 10:27

• Changed state: Accepted

[GoogleCodeExporter]

A bit busy with everything around buying a house in Alkmaar, Netherlands. Also 
had to prepare for the Eindhoven Metal Meeting :D. 
(http://www.eindhovenmetalmeeting.nl/)

Original comment by boukewou...@gmail.com on 13 Dec 2012 at 8:46

[GoogleCodeExporter]

I'll move the update to the Rubyripper community on Google+: 
https://plus.google.com/u/0/communities/103961841006414793555

The issues tracker isn't meant to be a forum.

Original comment by boukewou...@gmail.com on 18 Dec 2012 at 6:24

• Changed state: Fixed