|
|
bug18305.jpg (94,146 bytes) |
|
|
1/2) I don't think that anything changed in this area against MM4. I think it is rather that you are ussing different settings/target format ? Tracks are not ripped Track 1 to Track xx because you have multiple threads set up in Options > Performance > Ripping But each thread has exclusive access when ripping a track so the track is ripped as whole and only then the access is available for another encoding thread. So there is no constant seeking, but only one seek before ripping the particular track (confirmed also in your log). This used to work same way in MM4. So I am quite sure that if you use the same settings re CPU cores for ripping (Options > Performance) and the same target format then the results are same MM4 vs MM5. I would suggest to test ripping to WAV and attach both logs from MM4 and MM5 to compare, the times should be same. EDIT: The CD/drive is not in a good condition, see item 3 below 3) Re: Secure ripping: Seeing this at the beginning of your log and the CD/drive does not seem to be in a good condition as I see messages like: 00012264 99.29897308 [3640] hpCDEBurn: Buffers don't contain same content - read error !!! 00012265 99.29901123 [3640] ReadAudioSec(): Recover process, reading the 1. retry So this is the reason for the "stalling" as it is re-reading the same part again in the "recover process", MM4 uses exactly the same code/workflow, so it is really rather because of the CD/drive not in a good condition. |
|
|
I tested on 7 drives and all have same results in MM Secure Rip Speed is 2x. On other apps (image supplied) Secure Rip Speed is 8x and no read errors. I agree with you, I wanted to check as there was some user reports on unable to RIP. 1/2) When Drive spins up and do sequential sector read even one seek to track position spins down Drive sometimes from 40x to 2x and never return. So MM RIP CD 10+min While other apps RIP in 4-6min. 3) Maybe some additional checks/reset/toast msg/... to tell users there is a problem with Media reading. 4) Status MSG is bit unclear on progress maybe we should rephrase it for 5.1. Anyhow, I guess it is more for 5.1 and also based on user feedback/requests. bug18305_Secure_Sector_test.jpg (51,230 bytes) |
|
|
This is how secure read always worked (and why is slow), technicaly it reads a buffer (B1) corresponding to the length of the drive cache (usualy 2MB), then it reads another 2MB to another buffer (B2) (thus ensures that the CD drive cache is cleared), then it re-reads the first 2 MB again to compare with B1 and be sure that the data read is same (note that in your log the re-read data wasn't same thus MM5 re-reads it in the "Recover process"). If the data is same it continues reading the next 2 MB part to B1 to compare it with B2 data. i.e. it always reads whole data twice (into 2 buffers) and because of the seeking it is technicaly _more_ than twice slower (as you found). If you want fast rips then use 'Standard rip' + 'Verify ripped tracks' against AccurateRip DB. |
|
|
Seeing that you edited your note while I was replying: 1/2) >> one seek to track position spins down Drive sometimes from 40x to 2x and never return << What do you mean by never return? Based on my tests the seek spins down just for several seconds, isn't this the case for you? Can you test whether it is OK when single CPU core is configured for ripping in Options > Performence ? Maybe I could tweak it a bit and if e.g. 4 threads are going to rip/encode then prefer the tracks with lower numbers at first to keep the continuity (not sure how much it helps though). 3/4) Might be, probably with 5.1 target as you indicated |
|
|
1/2) Normally it returns back, but with even small damaged CDs it usually stays as error checking kick in and there is many read/seek going on (physically heard from drive itself) So what I would suggest that RIP is always in one thread and forced 01-99 tracks and progress on next only once previous one is done. Also in very rare cases if compression of previous track (eg. 01) is not done and encoder thread is not finished then MM creates new encoder thread on next ripped track (eg. 02) and so on, I have not seen that more than two encoding threads are activated and drive also rips even destination is on NAS and you are conected on slow WiFi. 3/4) Lets leave it for 5.1 and decide if it is still actual as needed |
|
|
As the multi-core ripping probably introduces more bad than good then I resolved it by forcing new default in 'Options > Performance' to use just single CPU core for ripping. This is "forced default" -- i.e. is used also for existing installs (not just clean installs). If that works fine then we could hardcode 1 CPU for ripping and remove the config entirely. => Fixed in 5.0.3.2610 |
|
|
Verified 2616 I have not observed any issues when using Single CPU RIP and Drive seeking/noise is much better. I found one case where multi CPU can improve performance <1s per ripped track where user is leveling Ripped tracks and not using direct encoding where destination/temp is UNC path and there is number of small tracks <1min. |
- Anonymous
