View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000243 | MMW v4 | Conversion/Leveling | public | 2003-03-27 14:49 | 2011-04-08 17:49 |
| Reporter | jiri | Assigned To | |||
| Priority | urgent | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Fixed in Version | 4.0 | ||||
| Summary | 0000243: 'Secure' Ripping and New CD/DVD Playback engine | ||||
| Description | MediaMonkey's ripping engine / playback engine leaves a bit to be desired in the sense that: a) Ripping may not be as robust as a product like EAC's for damaged or copy-protected CDs b) Various compatibility issues exist in relation to the current CD playback architecture Both of these issues can be resolved by using an alternate framework based upon either EAC or hpCDE. | ||||
| Tags | todoc-help | ||||
| Fixed in build | 1343 | ||||
| has duplicate | 0003165 | closed | rusty | MMW Wishlist | Secure ripping using AccurateRip or similar |
| related to | 0006972 | closed | Ludek | MMW v4 | CD Configuration inacessible from the Rip CD dialog |
| related to | 0006005 | closed | Ludek | MMW v4 | AccurateRip for verification of disc rips |
| related to | 0006982 | closed | Ludek | MMW v4 | Secure Read fails on some drives |
|
|
Note also: the application should provide some sort of indication that a CD is copy-protected (as does EAC). |
|
|
Here is the basics for Copy protected CDs, which are solved in AudioGrabber. 1. Normal Audio CD is Single Session Burned CD with Audio CD TOC No matter if it is written in track At Once or Disk At Once. 2. Copy Protected Audio CD is multi session CD with Valid Audio CD TOC in First Session and what ever in other: Here are the basics, done by comparing standard CD Player, Any Audio CD Playing app on Computers including MM and AudioGrabber: 1. Standard CD Player Reads Audio TOC from first session as Most Audio CD Players reads only first Session to get TOC from CD. This is why Copy protected CDs works on all CD Players. 2. Any app including MM. When CD is Inserted ASPI/SPTI returns TOC from Last finalized session which confuses App with wrong TOC. How to reproduce it: a) Write Audio CD with MultiSession (Track at once) and Allow futher burning (Don't Finalize disk) b) Continue MultiSession Audio CD, Delete last Audio session and write new Data session and finalize CD c) New tracks are played within Windows (second session), and only old songs is played on CD Players (First session) d) You have just burned Copy protected CD 3. When Loading AudioGrabber audio Sesion One can't be played. But when you use 'Get TOC (Track list) From Session Analyze' Tracks from first session are played. Note: It is very difficult to create this under Win XP. Somehow win XP is automaticaly changed CD type to Enhanced on RW WinOnCD 6.0 DVD Edition. I have successfully Burned CD On Win 98SE With WinOnCD 3.8. and basicly CD Must Be written so CD-Rom see only last Session without Audio CD Session. |
|
|
Assigned to Ludek to implement ripping using hpcde (details discussed over phone). |
|
|
When this is fully implemented, we no longer need in_CDReader.dll. I already removed it from the installer - *** Rusty *** please delete it from readme and any other place. In_CDA (our plug-in) is left there, it's for analog audio CD playback and so we can leave it there for users who would possibly need it. |
|
|
- Ripping, CD-Text reading, TOC reading, CDDBdiskID counting and all operations needed to replace akRip by hpCDe has been implemented in revison 1615. (build 1007) - Jitter corrected reading implemented in revision 1630. (build 1008) Assigned to Jiri in order to implement playback operation. |
|
|
Fixed in build 1008. - Playback works using the internal hpcde code. Using UsePluginForCDA=1 in MM.ini file (this flag was there also in previous MM versions) user can set that external plug-in will be used (e.g. in_CDReader.dll). |
|
|
Playback seems to work fine on the 2 systems I've tested, and ripping speed is dramatically improved! I'm not clear, however, on the extent to which this meets the requirement for secure burning. e.g. I don't see a configuration entry that allows the user to choose between standard ripping and 'secure ripping'. e.g. similar to EAC or Poikosoft's which offer: Secure Mode and Burst Mode (the point of the 'Secure mode' being that it bypasses 'copy-protections' and reads CDs that are in bad condition by doing multiple passes as required). Also, Ludek, can you confirm that all of the other settings on the current ripping configuration dialog are required for the new engine? |
|
|
I don't think it's of the very highest priority, but it would be nice if we have in 3.0 something like EAC describes at http://www.exactaudiocopy.de/eac3.html. I.e. every sector would be read at least twice and in case of any diference of these reads it would be read many times so that the really correct (hopefully) result is retrieved. |
|
|
Re: Ludek, can you confirm that all of the other settings on the current ripping configuration dialog are required for the new engine? Yes, all this settings is required now. Re: Described 'Secure ripping' mode: Put it off until another things with higher priority (like Podcasts managing) will be fully implemented. |
|
|
Extraction technology for secure ripping like EAC uses is described here: http://www.exactaudiocopy.de/en/index.php/overview/basic-technology/extraction-technology/ As can be seen we need function to flush device internal cache, but Primo doesn't allow any such function in their interface, asking them whether they plan to add it to the interface or whether we should implement it ourselves by using something like ioctl( BLKFLSBUF) or http://msdn.microsoft.com/en-us/library/aa365187(VS.85).aspx ? |
|
|
Implemented the secure ripping mode in build 1300 (just device cache flushing to add). In the secure mode MM reads every audio sector twice. That is one reason why the process is slower than other types. 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 selected error recovery quality) these 16 retries are read. So, in the worst case, bad sectors are read up to 82 times! But this effort will help the program to obtain the best result by comparing all of the retries. |
|
|
Implemented secure reading with flushing internal device cache - used SOLUTION 4 (the best one) in the private note above. Added in build 1300. |
|
|
Re-opened because of possibility to improve the implementation slightly. As discussed with Rusty via IM: In the second round of recover process (if the first round fails) we could slow the reading (drive rotational) speed to improve the accurancy. |
|
|
Improved the recovery process, so now the workflow is following: In the secure mode MM reads every audio sector twice. That is one reason why the process is slower than standard reading ( 2.3 times slower). But by using this technique non-identical sectors are detected. If an error occurs (read or sync error), the program starts the recovery process. It keeps on reading the failed sector, until eight of 16 retries are identical, but at maximum three times these 16 retries are read. So, in the worst case, bad sectors are read up to 48 times. The first round of the recovery process it reads the 16 retries and if there are 8 identical then uses these identical sectors for recovering the buffer so that the data are the most accurate. This effort will help the program to obtain the best result by comparing all of the retries. If it fails in the first round (16 entries read) then it slows down the drive rotational speed to half of the max speed and keeps reading the 16 retries again. If again there aren't found at least 8 identical then (in the third round) it slows down the drive rotational speed at fourth of the original speed. Whole the process is a little bit more complex, but the principle is mentioned in the paragraph above. Added in build 1300. |
|
|
Verified 1334 |
|
|
Tested 1334, and whenever Secure Rip is enabled, the final track on the disc is cut short by several seconds (whether during playback or during a rip). Tested this out on several CDs, and the problem is consistent. Switching to standard read solves the problem. |
|
|
Retested on All three of My drives with several CDs and all were ripped without problems. |
|
|
Clarification: I've closed the issue assuming that the problem is with my drive. Awaiting feedback from beta testers. |
|
|
I started to backup my CD collection to FLAC using Secure RIP. After 10+ CDs I think I have found one CD that Make problems. No DRM as CD is from early 90's. Assigning to myself for testing on other two PCs. NOTE: CD is playing flawlessly in MM. |
|
|
Peke, it looks like duplicate of 0006982 ? I fixed it based on the log in build 1343, see 0006982 |
|
|
Verified 1361 |
