Closed GoogleCodeExporter closed 9 years ago
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
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
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
Indeed. This project needs to pick up steam.
Original comment by perry...@gmail.com
on 27 Sep 2012 at 2:50
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
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
[deleted comment]
[deleted comment]
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
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
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
I second for revival of this project. Rubyripper rocks! :)
Original comment by kimmon.l...@gmail.com
on 16 Oct 2012 at 9:33
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
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
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
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
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
@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
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
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
No worries man.
Original comment by justlike...@gmail.com
on 22 Nov 2012 at 11:22
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
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
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
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
Original issue reported on code.google.com by
justlike...@gmail.com
on 20 Sep 2012 at 3:23