Thread: store disk TOC in tags

is it possible to store the disk TOC in the tags?

how large is the TOC?

Im asking so that lossless rips could later be re-verified with accuraterip

hello,

the toc is already saved in EAC's CDDB.dat, which usually
is never deleted. besides that, having wav files or some
other lossless format like monkey's audio you can (if
you have all files of a cd in one folder) recreate the toc
from a cue sheet and the amount of samples in each audio
file. such program doesnt exist yet afaik, but its,
together with a cue sheet which stores the pre track 1
gap, possible to recreate a toc and AR checksums from
lossless formats, once both authors decide to add such
functionality.

the results of each AR rip is stored in EAC's folder in
the file "AccurateRipUpload.bin" which you should copy
somewhere before submitting it (afaik it gets nuked upon
submission). this file would even allow to recompare rips
without touching the audio files again...

both databases store the FreeDB key, which can be computed
from a cd's amount of tracks and per track and allover
seconds...

the main problem with AR recalculation is, that your rip
becomes part of the AR database without any way to determin
that it was your rip. means, numbers of "confidence 1" only
would proove that your rip is in the AR db if such a "revalidate" feature ever appears....

also, im not sure how AR stores the result if you ripped
your disks twice for whatever reason... (maybe thats
determined by the machine key, i dont know)

for "ripping safety" i currently do this:
- have AR calibrated ripping drives
- rip single wave files with gaps appended to previous tracks
- store ripped waves as monkey's audio (plus mp3)
- create an EAC .log file automatically
- create a .cue sheet with UPC/ISRC enabled and secure gap detection (not using "noncompliant" as it is buggy until next version)
- copy paste the AR result in a .rip file
- store the results of the "check gaps for silence" into a .gaps file
- collect the AccurateRipUpload.bin files before submission

since i'm a coder i can recreate nearly all data from this
later, even for cds which got lost forever...

imho a "revalidate rips with AR" should be part of EAC,
since is has access to the CD toc by it's FreeDB key and
can easily read the AR db and compare a set of wav files
plus a cue sheet to confidence numbers greater than 1.

besides that AR should preserve its local .bin files
automatically to determin later what was ripped locally
and what came from others...

it would be nice if EAC also stores the results of the
gap detection in it's db (would allow to create cue files
at any time later) plus the results of the gap silence
detection (would allow to determin rips which can use
the "gaps removed" feature without data loss), store the
disk checksums of an AR rip in the db, store the track
checksums of an AR rip in the db, plus confidence amount
(allowing to recheck AR checksums upon confidence amount
or checksum change).


this would make us all "future proof" without having to store any additional files and without having to rerip
anything without having a good reason for it

combining all this in the log would do too, but could
maybe render current logs unusable...

the cue file would be way better for that, since it allows
REM statements. would be nice to have REMs with all db
entry data, so everyone can create whatever later results
from a cue (while keeping the cue compatible to current
burning software)...

let's hope and see what both authors decide to do :-)

http://www.audiosense.org/forum/showthread.php?t=181

Andre, I dont think this would be to hard to add, any chance?

The main problem is that the WAV file could have been created in any fashion. So a lot of users will misuse that function (if possible). In EAC accuraterip will only work if extraction with defined parameters is used.

cu, Andre

I dont understand how this would be "abused". Results should not be submitted, but for users to recheck the status of their lossless rips later this would be a great thing. If you are trying to fake a wave to match a CRC that would be nearly impossible

He was reffering to this :

AccurateRip will only work with extraction of tracks (no CDImages or Catalog or Index-based extraction).

AccurateRip will only be enabled on ripping if the option "Remove leading and trailing silence" is disabled.

AccurateRip will only be enabled on ripping if either the option "Overread into lead-in/out" AND/OR the option "Fill missing samples with silence" is activated.

There might be some problems with the first (last) track, often displaying a wrong CRC. The reason might be a wrongly activated "Overread into lead-in/out" option. Try to disable this option (but then activate "Fill missing offset samples with silence", see above).

-Martin.

then only allow the righting of the TOC to the meta data if accuraterip settings are enabled