EAC error correction question, Is it normal to always get the red bar working ? |
![]() ![]() |
EAC error correction question, Is it normal to always get the red bar working ? |
May 26 2012, 23:21
Post
#1
|
|
|
Group: Members Posts: 56 Joined: 19-August 05 Member No.: 24022 |
Hey guys,
I have been using EAC for many years. I'm currently using V0.95b3, in fact I guess that's the version I always used. Never gave me any problem However, there's a concern I've always had and never managed to figure it out. I think now is the time. Is it normal to ALWAYS get the error correction bar to work at some tracks on a CD ? I mean, even if the CD is in PERFECT conditions (brand new), I always get the red error correction bar working a bit on some tracks (always at the end of them). Like I said, I have burned TONS of CDs (mostly of them at perfect conditions) but I always get the error correction bar working at the end of like 2-5 tracks on each CD. Hence, I always get 99.9 quality on those 2-5 tracks per CD. The rest is 100% quality at the final report. I have never got a FULL result of 100% track quality on ANY of all the cds I burned, the error correction always appears on some tracks even if the CD is perfect. My question is, is this normal ? Is it something techinal regarding about EAC/drives that needs to do it at the end of some tracks ? Any comment would be really appreciated Thanks!! This post has been edited by Emiliano55: May 26 2012, 23:26 |
|
|
|
May 27 2012, 04:43
Post
#2
|
|
![]() Group: Super Moderator Posts: 9258 Joined: 1-April 04 Member No.: 13167 |
It's perfectly normal; an annoying side effect from the way EAC specifically requests and utilizes discrete chunks of data in order to satisfy its internal requirements to ensure secure ripping.
If your concern is the data on burned CDs, just compare ripped data from the newly created CD-R/RW against the source data used to create it. Be sure to account for offsets and the possible lack of preservation of the edge samples from either end of the disc due to an inability to overread/overwrite. This post has been edited by greynol: May 28 2012, 13:53 -------------------- Everything sounds the same until it is proven otherwise.
|
|
|
|
May 27 2012, 07:09
Post
#3
|
|
![]() Group: Members Posts: 452 Joined: 31-May 04 From: Czech Rep. Member No.: 14430 |
I've had the same "problem". It seems to be related to detection of gaps between tracks. I use burst (copy+test) since AccurateRip integration and switch to secure ripping only when some tracks don't match AR and fail the test.
-------------------- HD 238 Sansa Clip+ Vorbis q6; HD 380 Xonar DX FB2k FLAC
|
|
|
|
May 27 2012, 09:52
Post
#4
|
|
|
Group: Members Posts: 9 Joined: 29-September 06 From: Ostalb Member No.: 35763 |
Same here, sometimes I get the first row of the red box even at tracks on a brand new disc (EAC v1.0b3). It should be normal and no problem to quality.
|
|
|
|
May 27 2012, 18:23
Post
#5
|
|
![]() Group: Super Moderator Posts: 9258 Joined: 1-April 04 Member No.: 13167 |
It seems to be related to detection of gaps between tracks. I've seen no such correlation. EAC reads subcode information as a separate process, so I don't see how the existence of a 00 index has anything to do with it. I think it has to do with the fact that EAC overlaps 2MB burst reads in order to check for synchronization problems (when EAC is told the drive has the accurate stream feature) and pass/fail criteria was not met to determine if re-reads are necessary when the end of a track is reached because of the length of the track. Back to whether or not this is of any concern: http://www.digital-inn.de/exact-audio-copy...very-track.html This post has been edited by greynol: May 27 2012, 18:35 -------------------- Everything sounds the same until it is proven otherwise.
|
|
|
|
May 28 2012, 00:42
Post
#6
|
|
|
Group: Members Posts: 56 Joined: 19-August 05 Member No.: 24022 |
Thanks guys! I kinda knew that it must be something normal, but I wanted to make sure with the right people
|
|
|
|
![]() ![]() |
|
Lo-Fi Version | Time is now: 19th May 2013 - 20:13 |