Closed GoogleCodeExporter closed 9 years ago
Not sure about the GPL license after all, since it isn't stated explictly on
the
homepage. However, http://wiki.hydrogenaudio.org/index.php?title=XLD states
that the
license is GPL.
Sample log file from a newer version of Exact Audio Copy attached.
Original comment by mh31...@gmail.com
on 17 Mar 2010 at 11:35
Attachments:
src/XLD/XLDCDDAResult.m in the GUI source code tree contains the log-writing
code.
Original comment by mh31...@gmail.com
on 17 Mar 2010 at 11:39
Yes, it would be a very nice feature indeed!
Original comment by marcusvi...@gmail.com
on 19 Jun 2010 at 11:27
[deleted comment]
[deleted comment]
it would be nice yes i spend a lot of time on a site which accepts EAC and XLD
rips but so far does not ruby since they require an extensive log
i have no idea if this is difficult to add since i know nowt about programming
:))
but anyway yes
Original comment by holin...@googlemail.com
on 29 Jul 2010 at 2:53
This feature is really very important because there are some log checkers
(what.cd uses one, for example). If you realize it, Rubyripper will be complete
EAC replacement.
Original comment by loskut...@gmail.com
on 27 Nov 2010 at 5:25
I vote for this.
For inspiration, morituri supports this:
http://thomas.apestaart.org/morituri/trac/
Original comment by joh.sven...@gmail.com
on 20 Jan 2011 at 8:03
Adding this would ensure that thousands of people would drop EAC and run
rubyripper without hesitation!!
Original comment by chrisg...@gmail.com
on 17 Feb 2011 at 9:03
I've been longing for the day I can stop using Wine + EAC to rip on Ubuntu :)!
Original comment by mlapag...@gmail.com
on 18 Feb 2011 at 1:21
Also voting for this one. It's the only reason why I'm still stuck with EAC.
Original comment by akurei.w...@googlemail.com
on 19 Feb 2011 at 2:18
Please add this!!
Original comment by nyytecr...@gmail.com
on 2 Mar 2011 at 11:32
I would also like this feature and would certainly go back to using rubyripper.
Please consider adding it if you have the time/inclination. Thanks for the hard
work!
Original comment by bobspenc...@gmail.com
on 10 Mar 2011 at 1:00
This would be incredible. Let me know how I can help you to implement this.
Original comment by mlda...@gmail.com
on 22 Apr 2011 at 2:51
[deleted comment]
God dammit it people stop spamming these comments with messages that amount to
"me too". If you agree just star and move on. Only comment if you either have a
patch or information relevant to the implementation of the feature.
(And yes I recognise the irony that I too am decreasing the signal:noise ratio
but 10/13 of these comments add nothing.)
Original comment by Frankie....@gmail.com
on 29 Apr 2011 at 2:19
(It is not so much irony as it is hypocrisy. And parenthetical comments are
just so passive aggressive.) Anyway, I have plenty of free time on my hands and
really want this feature, so that I can generate logs that score 100% on What
without resorting to running EAC via wine. I'll see what I can come up with in
a week and hopefully submit a usable patch.
Note: I am definitely underestimating the triviality of this feature and will
most likely delete this comment in shame when I fail in my efforts. Wish me
luck... brb learning ruby.
Original comment by ryan.ro...@gmail.com
on 1 May 2011 at 8:23
I'd like to have a seperate class for creating the EAC logfile. The class
shouldn't calculate anything just make sure the logfile looks exactly like EAC.
I should be able to feed it some fake data and see to it that the logfile is
created correctly.
I wouldn't worry too much about new data or calculation that you need. Also,
first implement the default EAC log file.
You might wanna read Eloquent Ruby. It's a great and readable book about Ruby.
Hope that helps for a start ;)
Original comment by boukewou...@gmail.com
on 1 May 2011 at 8:39
I just read up to the dedication and am looking forward to a lazy sunday spent
reading the remaining 435 pages.
"To My Dad Charles J. Olsen Who never had a chance to write a book of his own,
which is a shame because it would have been hilarious"
Original comment by ryan.ro...@gmail.com
on 1 May 2011 at 9:22
Just another fellow soul stuck with having to run EAC through Wine, here to say
PLEASE make this happen.
Original comment by flying.d...@gmail.com
on 6 May 2011 at 11:02
The only thing that is missing in rubyripper, according to me.
Original comment by long.laz...@gmail.com
on 5 Aug 2011 at 9:39
Yes please, this would be awsome - EAC in WINE is a pain. If you did this, you
would gain me as a user.
Original comment by tomchaf...@gmail.com
on 29 Sep 2011 at 11:26
Going to suggest that this block on Issue 240 so as to properly report
timestamps of mismatching sectors in the log.
Original comment by comradec...@gmail.com
on 15 Nov 2011 at 2:54
Would like to propose the following as a possible log format generated by an
EAC-style logger for rubyripper doing an image rip.
Note that "Overread into Lead-In and Lead-Out" would be permanently set to "No"
based on the current implementation of rubyripper, but is given for
completeness (and comparison to EAC logs).
Based on this, the major dependencies which would need implementation aside
from revamping the logger in the master branch would be CRCs of individual
trials and peak level calculation. Although AccurateRip is given in this
sample, it would require actual support before it could be added to real logs.
Everything else would simply require the proper hooks into the correct settings
(if they are currently not being read, such as with the cdparanoia version
number).
I would envision track-wise releases being similar, except having the "Track N"
header instead of "Disc Image" as in the above EAC log files. Subsequent
trials would presumably be given timings and CRCs on subsequent lines, and the
"All chunks matched!" would be replaced with an appropriate warning about
mismatches. For example:
Trial 1: n seconds (#.##x)
Trial 2: n seconds (#.##x)
Sector mismatches found at the following times, requiring additional trials:
MM:SS:FF-MM:SS:FF
MM:SS:FF
Trial 3: ...
Irrecoverable sectors at the following times:
MM:SS:FF-MM:SS:FF
MM:SS:FF
Although those last three lines might be "Corrected all sector mismatches!" if
it was able to recover...
If any patching of the copy CRC was done to fix mismatched sectors, it'd
probably read:
Trial 1 CRC DEADBEEF
Trial 2 CRC DEADBEAD
...
Corrected CRC ADEADDAD
Naturally, "Copy OK" and "No errors occurred" would become "Copy finished" and
"There were errors" if there were any irrecoverable errors.
Also, since cdparanoia doesn't really expose detailed error information (just a
pictorial bar), we won't be able to report "Track Quality" or give any specific
errors (e.g. "Read drift" "Unreported loss of streaming in atomic read
operation" and so on), but simply the sectors which mismatched during
rubyripper's comparison AFTER cdparanoia has done any correction.
If we add support for ReplayGain to rubyripper directly, it might be nice to
add "Perceived loudness nn.n dB" in the log itself along with the Peak level
line (even though the Peak level line is 3 decimal places short of actually
being useful for ReplayGain)
Original comment by comradec...@gmail.com
on 15 Nov 2011 at 4:14
Attachments:
For comparison: an original EAC log, and the current logger output from
rubyripper for the same disc.
Original comment by comradec...@gmail.com
on 15 Nov 2011 at 4:19
Attachments:
And for a final comparison, XLD doing an image rip on the same disc.
Original comment by comradec...@gmail.com
on 15 Nov 2011 at 4:52
Attachments:
Here's a first draft of a patch to enable the EAC log-format I propose in
comment 24. Since this also includes some refactoring of Log to remove calls
to Log.add() from outside the Log class, it's possible I missed some
corner-cases. Furthermore, since Log is also tied with the short-summaries and
UI updates, it's possible I broke some some expected behavior with them. Log
could thus probably stand to be refactored a lot more nicely to cleanly
separate the log-file logging from these other aspects.
I also haven't tested the EAC logs with a bad rip or one which managed to
recover itself, so I am not entirely certain it will behave correctly with such
output.
One of the more concerning issues in this patch is that it seems that
calculating CRCs and peak levels for each track takes significantly more time
than simply calculating the MD5 sum did (I now try to calculate all three
together where possible to reduce the number of iterations through the
temporary file, but this doesn't seem to help all that much). I'm currently
not sure where the slowest part of this lies.
Fortunately, the refactoring of the Log class could potentially allow us to
effectively spin off this CRC calculation into a third thread since we can now
delay writing to the log by simply modifying the appropriate functions (e.g.
not writing out log lines for a given track until finishTrack() is called for
that track).
Finally, it would still be nice to grab the more specific error counts XLD
grabs when using cdparanoia, but I am not currently sure how it grabs those
figures, and they are currently excluded.
Original comment by comradec...@gmail.com
on 20 Nov 2011 at 5:27
Attachments:
Given the lack of comment on this bug, I've gone ahead and landed EAC-style
logging in the latest Git commit. It appears to be stable (although I haven't
tested with the new @logString formatting, I have no particular reason to think
it won't work).
Patch also fixes a bug in situations where a file is truncated (e.g.
out-of-space conditions).
Original comment by comradec...@gmail.com
on 11 Feb 2012 at 6:39
Awesome news! I'm going to test it now.
Original comment by akurei.w...@googlemail.com
on 11 Feb 2012 at 6:47
Okay, I pulled the latest git version, but there seems to be no option for
EAC-styled logfiles. Do I need to enable it somewhere? How do I test this?
Original comment by akurei.w...@googlemail.com
on 11 Feb 2012 at 7:07
It's the new default format for log files. No option needs to be enabled in
order to use this format.
Original comment by comradec...@gmail.com
on 15 Feb 2012 at 3:02
was unable to apply patch. how do I? I'm sorry but I newbie linux.
Original comment by cont...@henriquemota.com
on 7 Mar 2013 at 12:20
Original issue reported on code.google.com by
mh31...@gmail.com
on 17 Mar 2010 at 11:07Attachments: