Feature req: ability to create EAC-style log files

[GoogleCodeExporter]

It would be very nice if Rubyripper had an option to output Exact Audio 
Copy-style log files which are widely used and recognized. XLD has this 
ability and is released under the GPL, so maybe the XLD log-writing code 
could be incorporated into Rubyripper without too much work?

http://tmkk.hp.infoseek.co.jp/xld/

Sample EAC-style log attached.

Original issue reported on code.google.com by mh31...@gmail.com on 17 Mar 2010 at 11:07

Attachments:

• [One By One.log](https://storage.googleapis.com/google-code-attachments/rubyripper/issue-411/comment-0/One By One.log)

[GoogleCodeExporter]

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:

• [Hot Hot Heat - Bandages.log](https://storage.googleapis.com/google-code-attachments/rubyripper/issue-411/comment-1/Hot Hot Heat - Bandages.log)

[GoogleCodeExporter]

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

[GoogleCodeExporter]

Yes, it would be a very nice feature indeed!

Original comment by marcusvi...@gmail.com on 19 Jun 2010 at 11:27

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

Please add this!!

Original comment by nyytecr...@gmail.com on 2 Mar 2011 at 11:32

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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

[GoogleCodeExporter]

(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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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:

• eac.log

[GoogleCodeExporter]

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:

• eac.orig.log
• rubyripper.log

[GoogleCodeExporter]

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:

• xld.log

[GoogleCodeExporter]

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:

• 0001-Change-log-format-to-EAC.patch

[GoogleCodeExporter]

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

• Changed state: Fixed

[GoogleCodeExporter]

Awesome news! I'm going to test it now. 

Original comment by akurei.w...@googlemail.com on 11 Feb 2012 at 6:47

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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