Difference between revisions of "Exact Audio Copy"
m (update version) |
|||
| (78 intermediate revisions by 28 users not shown) | |||
| Line 1: | Line 1: | ||
| − | [http://www.exactaudiocopy. | + | {{featured}} |
| + | {{software Infobox | ||
| + | | name = Exact Audio Copy | ||
| + | | logo = [[Image:EAC icon.png|48px]] | ||
| + | | screenshot = [[Image:EAC_screenshot.png|250px|Exact Audio Copy screenshot]] | ||
| + | | caption = popular secure ripper with C2 error correction | ||
| + | | maintainer = Andre Wiethoff | ||
| + | | repository = | ||
| + | | released = {{start date and age|1998|06|25}}<ref>[http://www.exactaudiocopy.de/en/index.php/resources/whats-new/whats-new/ What's new » Exact Audio Copy]</ref> | ||
| + | | stable_release = 1.6 | ||
| + | | stable_release_date = {{start date and age|2020|11|11}} | ||
| + | | preview_release = N/A | ||
| + | | operating_system = Windows, Linux/BSD (Wine Emulation) | ||
| + | | use = Digital Audio Extraction | ||
| + | | license = Proprietary, Cardware | ||
| + | | website = [http://www.exactaudiocopy.org/ exactaudiocopy.org] | ||
| + | }} | ||
| + | {{EAC guides}} | ||
| + | '''Exact Audio Copy''' ('''EAC''' for short) is a freeware software that can be used to extract tracks from an [[Audio CD]] to your computer's hard disk. What makes EAC special compared to other rippers is the fact that it is capable of reading audio CDs almost perfectly. | ||
| + | |||
EAC uses various methods for extracting audio data. EAC can also invoke externally installed encoders, thereby making it possible to simultaneously rip and encode audio data to the format of your choice. | EAC uses various methods for extracting audio data. EAC can also invoke externally installed encoders, thereby making it possible to simultaneously rip and encode audio data to the format of your choice. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | == Features of Exact Audio Copy == | |
| + | * Usage of the Windows 95 and Windows NT ASPI Interface, so both SCSI and ATAPI CD-ROM drives are supported | ||
| + | * Hidden sector synchronization (jitter correction) | ||
| + | * Secure, fast and burst extraction methods selectable. Fast extraction should run at the same speed as other grabbers, but is probably not exact anymore. Burst mode just grabs the audio data without any synchronization. | ||
| + | * Read error and complete loss of sync detection and correction in secure modes, as far as possible | ||
| + | * Output of time positions of all non-exact corrections and listen to these positions | ||
| + | * Copy of ranges of music data, not only tracks | ||
| + | * Automatic Speed reduction on errors and fallback afterwards | ||
| + | * Normalization of extracted audio | ||
| + | * Usage of the Windows Audio Compression Manager (ACM Codecs) for direct compression e.g. to MP3 waves | ||
| + | * Support for the BladeEnc DLL that is usable like an ACM Codec for online MP3 compression | ||
| + | * Support of external MP3, VQF, RA and AAC encoders for automatic compression after extraction | ||
| + | * Batch compression and decompression of/to WAV files | ||
| + | * Compression offset support for exact compression/decompression | ||
| + | * Detection of pre-track gaps | ||
| + | * Detection of silence in pre-track gaps | ||
| + | * Automatic creation of CUE sheets for CDRWin, including all gaps, indices, track attributes, UPC and ISRC | ||
| + | * CD player functionality and prelistening to selected ranges | ||
| + | * Automatic detection of drive features, whether a drive has an accurate stream and/or does caching | ||
| + | * Sample Offsets for drives with no accurate streams, including the option of filling up missing samples with silence | ||
| + | * Option for synchronizing tracks for non-accurate stream drives | ||
| + | * Filename editing with local and remote CDDB database and cdplayer.ini support and more features like ID3 tagging | ||
| + | * Browse and edit local database | ||
| + | * Local CDDB support | ||
| + | * Record and Loop Record functions for recording from LP, radio, etc. | ||
| + | * Automatic rename of MP3 files according to their ID3 tag | ||
| + | * Catalog extraction function | ||
| + | * Multisession (CD-Extra) support | ||
| + | * CD-Text support | ||
| + | * CD-Write support for some drives | ||
| + | * ID3 Tag editor with drag and drop possibility from track listing and database | ||
| + | * Glitch removal after extraction | ||
| + | * Small WAV editor with the following functionality: delete, trim, normalize, pad, glitch removal, pop detection, interpolation of ranges, noise reduction, fade in/out, undo (and more) | ||
| + | * Program is Cardware, so feel free to copy | ||
| − | === | + | ===Removed features=== |
| + | EAC 0.9 beta 1 (21 Jan 2001) through 0.95 prebeta 3 (11 May 2003) had manual TOC detection as an option, "useful if a CD is defective and displays wrong track positions or data tracks instead of audio; EAC will try to detect the CD structure by analysis." This could also be used to detect pre-emphasis and copyright flags in the subcode, since they're sometimes missing from the TOC. The manual TOC detection feature was removed in 0.95 prebeta 4 (9 Nov 2003) due to European legislation which would outlaw software capable of circumventing a certain type of CD copy protection involving erroneous TOC data.<ref>Andre said at the time: "The German magazine c't published [http://www.heise.de/ct/artikel/Die-Grenzen-des-Erlaubten-290330.html an article] [about] whether EAC is or is not violating a German law against circumvention of copy protections on audio CDs. Some of the experts they asked had the opinion that the function of retrieving the native TOC is at best working at the limit of legality. Due to that article and to eliminate any possibility of legal problems, I decided to remove that function (although I am pretty sure that it is absolutely legal). I always try to make sure to be fully compliant with German law, even if I would interpret the law absolutely differently."</ref> | ||
| − | + | A related feature, "retrieve native TOC", was available through 0.95 beta 3 (30 Aug 2005); it reloaded the TOC info from the lead-in, same as ejecting and reinserting the disc, but without losing metadata. | |
| − | + | ||
| − | + | EAC 1.0 beta 1 (23 Nov 2010) removed the following features: | |
| + | * Compression offset | ||
| + | * ID3v1 tag editor | ||
| + | * Support for pre-XP versions of Windows (95/98/Me/NT4/2000) | ||
| − | + | EAC 1.0 beta 3 (22 Sep 2011) removed the option to not use null samples for CRC calculations. | |
| − | + | ===Limitations=== | |
| + | * The log for non-Test & Copy burst-mode rips will say "No errors occured"<!--yes, occured is misspelled--> on all tracks, but in this mode, EAC does not actually check for inconsistent data. | ||
| + | * Pre-emphasis and copyright flags are only checked for in the TOC, which sometimes doesn't match the flags in the subcode. Usually the subcode is correct. | ||
| + | * ISRC codes are sometimes read incorrectly.<ref>[http://www.studio-nibble.com/cd/index.php?title=Exact_Audio_Copy_(EAC) Exact Audio Copy (EAC)] on CDHistory</ref> | ||
| − | + | == How it works == | |
| − | + | === Extraction technology === | |
| + | In secure mode, this program reads every audio sector at least twice. That is one reason why the program is so slow. But by using this technique non-identical sectors are detected. If an error occurs (read or sync error), the program keeps on reading this sector, until eight of 16 retries are identical, but at maximum one, three or five times (according to the error recovery quality) these 16 retries are read. So, in the worst case, bad sectors are read up to 82 times! But this will help the program to obtain best result by comparing all of the retries. If it is not sure that the stream is correct (at least it can be said at approx. 99.5%) the program will tell the user where the (possible) read error occurred. The program also tries to adjust the jitter artifacts that occur on the first block of a track, so that each extraction should be exactly the same. On drives found to have the ''accurate stream'' feature, this is guaranteed. Of course, this is a little bit more complex, especially with some CD drives which have caching. When these drives cache audio data, every sector read will be read from cache and is identical. I initially implemented two ways of dealing with the caching problem. First there is an extra option for resetting the cache for use the the old secure mode (the one being kept for compatibility reasons). In the current beta version, the cache will still be reset by resetting the drive completely. You might imagine that this would slow down the reading process very badly. | ||
| − | + | That is why it was implemented three new read modes in version 0.85beta. One really fast mode (up to half of maximum speed) is only for non-caching, accurate stream CD-ROM drives. The second one could be used for caching, accurate stream drives and the last one will work with drives that don't have accurate streams, or do caching. The last two will be much slower, when no read errors occur it will usually something around a third to a fourth of the drives maximum speed. | |
| + | For testing, it was used a Plextor 14/32 drive that does no caching and a Teac R56S-600 drive that does caching. Furthermore the Plextor 14/32 supports the ''accurate stream'' feature, so it produces no jitter artifacts on any stream. | ||
| − | + | This program is really damn slow in secure mode in comparison with other grabbers, but the program checks every sector over and over to get the correct data with high certainty. If you don't like this feature of EAC and prefer fast copies instead of secure copies, you should use the fast or burst extraction option in the options menu. But of course in fast mode, the program will no longer be able to find read errors. Only if a read error occurs in a sector synchronization area, will a sync error will still be displayed. Fast mode is sector synchronized with 2 blocks of 23 as synchronization blocks. Burst copy is even worse, no synchronization is done, enabling extraction at maximum speed of the drive. No error checking of any kind can be performed. If the stream ever breaks, it will tell the user in the status report by showing up suspicious positions. Of course this is only heuristic; there needn't be any errors on that positions; moreover there could be errors that are not found at all. | |
| + | A new option for selecting the error recovery quality will determine how often these blocks of 16 reads will be done before giving up and working with the results obtained so far. For bad CDs, low error recovery quality will be fastest, but high recover quality should give best results. | ||
| + | === Gap technology === | ||
| + | In the new versions of EAC it is possible to detect pre-track gaps. These are the pauses between two tracks. Usually they are two seconds long and a CD player will display a negative time during this pause. By enabling the option ''Detect Pre-Track Gaps'' it will be possible to detect all gap-lengths by reading the sub-channel information. Because this information is not stored on the CD directly retrievable, EAC has to search for the position a track ends. This search is quite fast, but it still takes on average a second per track. That's why I made it possible to disable it in the options. Besides that option you can choose to add the gaps to the previous track nevertheless. Otherwise you can choose either to append the gap to the correct track or to leave it out . A benefit of performing the detection and getting the gap times is the selection of a range to copy. There the correct times will be displayed. One last word on this topic: Because these pre-track gaps are found by testing positions, it is possible that it will not be 100% exact. But in most cases it will be correct. | ||
| − | + | === Automatic feature detection technology === | |
| − | + | From version 0.8 beta on it is possible to autodetect CD-ROM drive features. For each drive the program builds a separate drive options page. On this option page this function can be called. | |
| − | == | + | There are two different features that will be checked by EAC: First if the stream is accurate and second, if the drive caches audio data. Even if the drive has a cache (drive specifications), it does not automatically mean that the drive uses the cache for audio extractions. |
| − | + | The test for the accurate stream feature should be always correct, but testing for cache will give some problems with drives that extract audio very slowly (under 4× speed). If results are uncertain (given e.g. two different results on different tests), you should assume that the drive does caching. The new secure mode for non-accurate and/or caching drives should work for all drives. The other new read modes are only a bit faster. If testing for accurate stream only sometimes gives a negative result, then you could nevertheless try to use the accurate secure mode. | |
| − | + | ||
| − | + | ||
| − | === | + | === Track synchronization technology === |
| + | Usually CD audio extraction programs will extract one track after another. This could cause some problems on CD-ROM drives which are not accurate, when using a CD which has no gaps. When this option is enabled in the EAC options, EAC will synchronize a track with a preceding track if there is no silence at the track junction, so track transitions will be free from jitter artefacts (e.g. on live recordings). | ||
| − | === | + | === Offset technology === |
| + | ''Sample Offset'' is another feature of EAC, it will help to always get the same WAVs compared to a different reader and to prevent generation losses. Nearly all drives can not position the head correctly. That means if the program tells the drive to read block 10000 it will probably read data somewhere in block 9998 instead. But this is not visible to the reading program, it won't know if it is really the data it wanted. Usually the head will be set always to a fixed offset before or after the correct read position. So it is possible to detect this offset once and use it for all CDs coming afterwards. To find out the offset of any drive the offset has to be calculated relative to an absolute offset (reference offset). | ||
| − | + | To implement this detection for all drives some bytes from common CDs (reference CDs) are used. These are the reference each CD-ROM drive has to compare with. Of course it was implemented only a limited selection of CDs that can be used to detect this offset. Sometimes there are different versions (releases) of the same CD, but only the same press like the one that was used will work. Furthermore, drives that have jitter are unable to position their heads correctly. So you should activate the secure or fast extraction method and moreover if your drive does caching, activate no-caching emulation. The ''Searching Track Start'' algorithm tries to find the correct start position even if jitter occurs. But this is not always possible, mainly if the drive jitters too much. But it can be shown that nearly 80% of the reads will get the same results. A drive's characteristic offset can be found automatically from the CD from on the list of reference CDs. Because of the mentioned jitter error the value given back is also not 100% sure. You should start the test several times and remember to activate emulate no-caching if necessary. Then you should get one value that occurs more often than other values. '''You should use this test on two different CDs at least! Both tests should give back the same value!''' | |
| + | As different models of common CD-R writer usually do not add the same offset on writing, it seems that also big CD manufactures also do not always press the same offset on their CDs. So it was determined the most common offset of pressed CDs and integrated it into the offset detection routines. | ||
| + | Please help us measure more reference CDs. If you have a Plextor 14/32 32× CD-ROM drive, we know the offset. So all you have to do is run some popular disks from your own collection through it with a utility you could download here and send us the output. | ||
| − | == | + | == See also == |
| + | * [[EAC release history]] | ||
| + | * [[EAC and Cue Sheets]] ASCII formats explained | ||
| + | * [[EAC Vs CDex SecureMode | EAC secure mode versus CDex full paranoia]] (by Pio2001) | ||
| + | * [[REACT]] 2 integration for running EAC scripts | ||
| − | + | == Notes == | |
| + | <references/> | ||
| − | + | == External links == | |
| + | * [http://www.digital-inn.de/forum271/ EAC forums] [dead link] | ||
| − | + | [[Category:CD Rippers]] | |
| − | + | [[Category:Software]] | |
| − | + | ||
| − | + | ||
Latest revision as of 03:49, 11 November 2020
| |
|---|---|
 popular secure ripper with C2 error correction | |
| Developer(s) | Andre Wiethoff |
| Release information | |
| Initial release | June 25, 1998; 26 years ago[1] |
| Stable release | 1.6 (November 11, 2020; 4 years ago) |
| Preview release | N/A |
| Compatibility | |
| Operating system | Windows, Linux/BSD (Wine Emulation) |
| Additional information | |
| Use | Digital Audio Extraction |
| License | Proprietary, Cardware |
| Website | exactaudiocopy.org |
| Configuration | |
|---|---|
|
| |
| Compression | |
| Other | |
Exact Audio Copy (EAC for short) is a freeware software that can be used to extract tracks from an Audio CD to your computer's hard disk. What makes EAC special compared to other rippers is the fact that it is capable of reading audio CDs almost perfectly.
EAC uses various methods for extracting audio data. EAC can also invoke externally installed encoders, thereby making it possible to simultaneously rip and encode audio data to the format of your choice.
Contents
Features of Exact Audio Copy
- Usage of the Windows 95 and Windows NT ASPI Interface, so both SCSI and ATAPI CD-ROM drives are supported
- Hidden sector synchronization (jitter correction)
- Secure, fast and burst extraction methods selectable. Fast extraction should run at the same speed as other grabbers, but is probably not exact anymore. Burst mode just grabs the audio data without any synchronization.
- Read error and complete loss of sync detection and correction in secure modes, as far as possible
- Output of time positions of all non-exact corrections and listen to these positions
- Copy of ranges of music data, not only tracks
- Automatic Speed reduction on errors and fallback afterwards
- Normalization of extracted audio
- Usage of the Windows Audio Compression Manager (ACM Codecs) for direct compression e.g. to MP3 waves
- Support for the BladeEnc DLL that is usable like an ACM Codec for online MP3 compression
- Support of external MP3, VQF, RA and AAC encoders for automatic compression after extraction
- Batch compression and decompression of/to WAV files
- Compression offset support for exact compression/decompression
- Detection of pre-track gaps
- Detection of silence in pre-track gaps
- Automatic creation of CUE sheets for CDRWin, including all gaps, indices, track attributes, UPC and ISRC
- CD player functionality and prelistening to selected ranges
- Automatic detection of drive features, whether a drive has an accurate stream and/or does caching
- Sample Offsets for drives with no accurate streams, including the option of filling up missing samples with silence
- Option for synchronizing tracks for non-accurate stream drives
- Filename editing with local and remote CDDB database and cdplayer.ini support and more features like ID3 tagging
- Browse and edit local database
- Local CDDB support
- Record and Loop Record functions for recording from LP, radio, etc.
- Automatic rename of MP3 files according to their ID3 tag
- Catalog extraction function
- Multisession (CD-Extra) support
- CD-Text support
- CD-Write support for some drives
- ID3 Tag editor with drag and drop possibility from track listing and database
- Glitch removal after extraction
- Small WAV editor with the following functionality: delete, trim, normalize, pad, glitch removal, pop detection, interpolation of ranges, noise reduction, fade in/out, undo (and more)
- Program is Cardware, so feel free to copy
Removed features
EAC 0.9 beta 1 (21 Jan 2001) through 0.95 prebeta 3 (11 May 2003) had manual TOC detection as an option, "useful if a CD is defective and displays wrong track positions or data tracks instead of audio; EAC will try to detect the CD structure by analysis." This could also be used to detect pre-emphasis and copyright flags in the subcode, since they're sometimes missing from the TOC. The manual TOC detection feature was removed in 0.95 prebeta 4 (9 Nov 2003) due to European legislation which would outlaw software capable of circumventing a certain type of CD copy protection involving erroneous TOC data.[2]
A related feature, "retrieve native TOC", was available through 0.95 beta 3 (30 Aug 2005); it reloaded the TOC info from the lead-in, same as ejecting and reinserting the disc, but without losing metadata.
EAC 1.0 beta 1 (23 Nov 2010) removed the following features:
- Compression offset
- ID3v1 tag editor
- Support for pre-XP versions of Windows (95/98/Me/NT4/2000)
EAC 1.0 beta 3 (22 Sep 2011) removed the option to not use null samples for CRC calculations.
Limitations
- The log for non-Test & Copy burst-mode rips will say "No errors occured" on all tracks, but in this mode, EAC does not actually check for inconsistent data.
- Pre-emphasis and copyright flags are only checked for in the TOC, which sometimes doesn't match the flags in the subcode. Usually the subcode is correct.
- ISRC codes are sometimes read incorrectly.[3]
How it works
Extraction technology
In secure mode, this program reads every audio sector at least twice. That is one reason why the program is so slow. But by using this technique non-identical sectors are detected. If an error occurs (read or sync error), the program keeps on reading this sector, until eight of 16 retries are identical, but at maximum one, three or five times (according to the error recovery quality) these 16 retries are read. So, in the worst case, bad sectors are read up to 82 times! But this will help the program to obtain best result by comparing all of the retries. If it is not sure that the stream is correct (at least it can be said at approx. 99.5%) the program will tell the user where the (possible) read error occurred. The program also tries to adjust the jitter artifacts that occur on the first block of a track, so that each extraction should be exactly the same. On drives found to have the accurate stream feature, this is guaranteed. Of course, this is a little bit more complex, especially with some CD drives which have caching. When these drives cache audio data, every sector read will be read from cache and is identical. I initially implemented two ways of dealing with the caching problem. First there is an extra option for resetting the cache for use the the old secure mode (the one being kept for compatibility reasons). In the current beta version, the cache will still be reset by resetting the drive completely. You might imagine that this would slow down the reading process very badly.
That is why it was implemented three new read modes in version 0.85beta. One really fast mode (up to half of maximum speed) is only for non-caching, accurate stream CD-ROM drives. The second one could be used for caching, accurate stream drives and the last one will work with drives that don't have accurate streams, or do caching. The last two will be much slower, when no read errors occur it will usually something around a third to a fourth of the drives maximum speed. For testing, it was used a Plextor 14/32 drive that does no caching and a Teac R56S-600 drive that does caching. Furthermore the Plextor 14/32 supports the accurate stream feature, so it produces no jitter artifacts on any stream.
This program is really damn slow in secure mode in comparison with other grabbers, but the program checks every sector over and over to get the correct data with high certainty. If you don't like this feature of EAC and prefer fast copies instead of secure copies, you should use the fast or burst extraction option in the options menu. But of course in fast mode, the program will no longer be able to find read errors. Only if a read error occurs in a sector synchronization area, will a sync error will still be displayed. Fast mode is sector synchronized with 2 blocks of 23 as synchronization blocks. Burst copy is even worse, no synchronization is done, enabling extraction at maximum speed of the drive. No error checking of any kind can be performed. If the stream ever breaks, it will tell the user in the status report by showing up suspicious positions. Of course this is only heuristic; there needn't be any errors on that positions; moreover there could be errors that are not found at all. A new option for selecting the error recovery quality will determine how often these blocks of 16 reads will be done before giving up and working with the results obtained so far. For bad CDs, low error recovery quality will be fastest, but high recover quality should give best results.
Gap technology
In the new versions of EAC it is possible to detect pre-track gaps. These are the pauses between two tracks. Usually they are two seconds long and a CD player will display a negative time during this pause. By enabling the option Detect Pre-Track Gaps it will be possible to detect all gap-lengths by reading the sub-channel information. Because this information is not stored on the CD directly retrievable, EAC has to search for the position a track ends. This search is quite fast, but it still takes on average a second per track. That's why I made it possible to disable it in the options. Besides that option you can choose to add the gaps to the previous track nevertheless. Otherwise you can choose either to append the gap to the correct track or to leave it out . A benefit of performing the detection and getting the gap times is the selection of a range to copy. There the correct times will be displayed. One last word on this topic: Because these pre-track gaps are found by testing positions, it is possible that it will not be 100% exact. But in most cases it will be correct.
Automatic feature detection technology
From version 0.8 beta on it is possible to autodetect CD-ROM drive features. For each drive the program builds a separate drive options page. On this option page this function can be called. There are two different features that will be checked by EAC: First if the stream is accurate and second, if the drive caches audio data. Even if the drive has a cache (drive specifications), it does not automatically mean that the drive uses the cache for audio extractions. The test for the accurate stream feature should be always correct, but testing for cache will give some problems with drives that extract audio very slowly (under 4× speed). If results are uncertain (given e.g. two different results on different tests), you should assume that the drive does caching. The new secure mode for non-accurate and/or caching drives should work for all drives. The other new read modes are only a bit faster. If testing for accurate stream only sometimes gives a negative result, then you could nevertheless try to use the accurate secure mode.
Track synchronization technology
Usually CD audio extraction programs will extract one track after another. This could cause some problems on CD-ROM drives which are not accurate, when using a CD which has no gaps. When this option is enabled in the EAC options, EAC will synchronize a track with a preceding track if there is no silence at the track junction, so track transitions will be free from jitter artefacts (e.g. on live recordings).
Offset technology
Sample Offset is another feature of EAC, it will help to always get the same WAVs compared to a different reader and to prevent generation losses. Nearly all drives can not position the head correctly. That means if the program tells the drive to read block 10000 it will probably read data somewhere in block 9998 instead. But this is not visible to the reading program, it won't know if it is really the data it wanted. Usually the head will be set always to a fixed offset before or after the correct read position. So it is possible to detect this offset once and use it for all CDs coming afterwards. To find out the offset of any drive the offset has to be calculated relative to an absolute offset (reference offset).
To implement this detection for all drives some bytes from common CDs (reference CDs) are used. These are the reference each CD-ROM drive has to compare with. Of course it was implemented only a limited selection of CDs that can be used to detect this offset. Sometimes there are different versions (releases) of the same CD, but only the same press like the one that was used will work. Furthermore, drives that have jitter are unable to position their heads correctly. So you should activate the secure or fast extraction method and moreover if your drive does caching, activate no-caching emulation. The Searching Track Start algorithm tries to find the correct start position even if jitter occurs. But this is not always possible, mainly if the drive jitters too much. But it can be shown that nearly 80% of the reads will get the same results. A drive's characteristic offset can be found automatically from the CD from on the list of reference CDs. Because of the mentioned jitter error the value given back is also not 100% sure. You should start the test several times and remember to activate emulate no-caching if necessary. Then you should get one value that occurs more often than other values. You should use this test on two different CDs at least! Both tests should give back the same value! As different models of common CD-R writer usually do not add the same offset on writing, it seems that also big CD manufactures also do not always press the same offset on their CDs. So it was determined the most common offset of pressed CDs and integrated it into the offset detection routines. Please help us measure more reference CDs. If you have a Plextor 14/32 32× CD-ROM drive, we know the offset. So all you have to do is run some popular disks from your own collection through it with a utility you could download here and send us the output.
See also
- EAC release history
- EAC and Cue Sheets ASCII formats explained
- EAC secure mode versus CDex full paranoia (by Pio2001)
- REACT 2 integration for running EAC scripts
Notes
- ↑ What's new » Exact Audio Copy
- ↑ Andre said at the time: "The German magazine c't published an article [about] whether EAC is or is not violating a German law against circumvention of copy protections on audio CDs. Some of the experts they asked had the opinion that the function of retrieving the native TOC is at best working at the limit of legality. Due to that article and to eliminate any possibility of legal problems, I decided to remove that function (although I am pretty sure that it is absolutely legal). I always try to make sure to be fully compliant with German law, even if I would interpret the law absolutely differently."
- ↑ Exact Audio Copy (EAC) on CDHistory
External links
- EAC forums [dead link]
