Super Slow MP3 Ripping On Super Fast System[BUG# 5906]

[BluBear]

My system is an i7-920 (quad core at 2.67Ghz) with 12GB of RAM, running Vista Home Premium 64bit. Media Monkey is performimg badly while ripping CDs to 256bit CBR. All other music programs on my system (iTunes & WMP) perform rips at blinding speed. Only MM 3.1.1256 Gold takes about 12 to 20 minutes for a single CD. It is not the encoding process that is slowing things down, as separately extracted WAV files enode to 256bit CBR MP3 at breakneck speed. Rather, it is the CD transfer rate that chugs along at a leisurely 2x - 3x rate, typically after the first track of a CD rips at exellent speed. At times it seems to crawl to a standstill. CPU utilization is pretty much nonexistant througout. Mt DVD player tests at an average transfer speed of 32X ofr a typical CD, and all other applications on my system utilizing the drive substantiate this result. The player is an internal Optiarc SATA1 device. At this point I can no longer use MM for ripping my CD library. Now that the auto tag feature (via Amazon) is also broken, MM's utility is diminishing at an alarming rate.

[Lowlander]

Are you using MediaMonkey Gold?

Try submitting a debug log to support as described in the Bug Report forum, this might give the developers insight into why this is happening on your system.

[Peke]

Tracked as http://www.ventismedia.com/mantis/view.php?id=5906

[Ludek]

I have no issues on my Laptop Lenovo ThinkPad SL500, Core 2 Duo, Win XP SP2.
Whole CD is ripped into M4A in 2 minutes.

Does the slowdown appear also when you rip directly to WAV ?
Does the slowdown appear when you decrease Tools|Options|Performance|Riiping: from [All] to [2] ?

Maybe it is somehow Quad core or Vista related.



Re: the Auto-tag from web issue. You need update to the last build (1261) that fixes the issue.

[BluBear]

I have no issues on my Laptop Lenovo ThinkPad SL500, Core 2 Duo, Win XP SP2.
Whole CD is ripped into M4A in 2 minutes.

Does the slowdown appear also when you rip directly to WAV ?
Does the slowdown appear when you decrease Tools|Options|Performance|Riiping: from [All] to [2] ?
Maybe it is somehow Quad core or Vista related.

Right after a reboot MM typically rips the first track of a CD at excellent speed. That is, I can hear the drive spin at a high rate.
After that it gets really quiet and the transfer times from the CD/DVD burner fall off dramatically. If I switch to WMP or iTunes once in this state, transfers from the CD/DVD drive remain slow until another reboot.
After reboot, using only WMP and iTunes, this behaviour is not present and I can use the CD/DVD drive all day at nominal performance, unless I use MM again. It is as if MM sets the max drive speed lower and never explicitly resets it back to max value.
I will try using MM to rip to WAV. I have used other apps to do this and MM has no problems at all encoding from WAV to MP3. It just screams through the process. It is not the encoding process, it is clearly the optical drive transfer rates that slow ripping down. Seems that the interface to my SATA optical drive is the culprit.
I will try your suggestion and set the performance setting to 2 cores.

My old XP Professional system with a 3.2GHz P4 has no problems at all, and all other apps (WMP and iTunes) consistently achieve similar performance.

[BluBear]

Forgot to mention above that I am using build 1261 now. Thanks for resolving the auto-tag issue so quickly, guys!

[Guest]

Hello,

I have exactly the same problem like BluBear.

Saludos

[Peke]

Should be fixed in 1266

[BluBear]

I have installed 1266 and the problem remains as is.
There is further information I can provide:
- upon first boot of the system, the first track of a CD rips at excellent speed, the second and all subsequent tracks slow to a crawl
- using an optical drive information utility, the drive then reports a max speed of 40X. Not running MM first the utility reports 48X (another utility even reports 96X)
- any transfer speed tests using drive utilities top out at 4X speed, any applications using the drive act like the drive is dead slow at 4X
- rebooting the system without power down does not change the behaviour
- a cold boot resets the system to proper operation
- NOT using MM results in expected behaviour for the drive using any and all applications

it really looks like MM's optical drive engine sets parameters in the drive itself after finishing the first track (warm reboot doesn't clear entries like "max. speed") and not for the better.
Reading related posts in this forum indicating odd behaviour after the first track has been read/ripped/burned, it would appear that there is a fundamental flaw in the way the engine interacts with some drives. I suspected the drive's FW at first, but the fact that all other applications I use work just fine, precludes that reasoning.

[Ludek]

I have installed 1266 and the problem remains as is.
There is further information I can provide:
- upon first boot of the system, the first track of a CD rips at excellent speed, the second and all subsequent tracks slow to a crawl
- using an optical drive information utility, the drive then reports a max speed of 40X. Not running MM first the utility reports 48X (another utility even reports 96X)
- any transfer speed tests using drive utilities top out at 4X speed, any applications using the drive act like the drive is dead slow at 4X
- rebooting the system without power down does not change the behaviour
- a cold boot resets the system to proper operation
- NOT using MM results in expected behaviour for the drive using any and all applications

it really looks like MM's optical drive engine sets parameters in the drive itself after finishing the first track (warm reboot doesn't clear entries like "max. speed") and not for the better.
Reading related posts in this forum indicating odd behaviour after the first track has been read/ripped/burned, it would appear that there is a fundamental flaw in the way the engine interacts with some drives. I suspected the drive's FW at first, but the fact that all other applications I use work just fine, precludes that reasoning.

Ok, so let me know whether does the slowdown appear also when you decrease Tools|Options|Performance|Ripping: from [All] to [1]

[Peke]

@BluBear
Can you send Debug log and c:\HPCDE.log using 1266 to ls [.@.] MediaMonkey ... COM and pavle [.@.] MediaMonkey ... COM

[BluBear]

@BluBear
Can you send Debug log and c:\HPCDE.log using 1266 to ls [.@.] MediaMonkey ... COM and pavle [.@.] MediaMonkey ... COM

I have sent the log.

I also tried setting performance to "1" for ripping, and subsequently for all processes. This delayed the onset of the problem somewhat, in that the 6th ot 7th track of the CD (instead of the 2nd) would be slow. This was about halfway through my test CD-ROM in terms of total track time. I did a lot of power cycles tonight.

Thanks for looking into this, guys. Let me know if I can be of further assistance.

[BluBear]

Forgot to mention that the system did not create a HPCDE.log file during my test.

[Ludek]

Peter,
please give a try with this hpCDBurn.dll : http://rapidshare.com/files/279887471/hpCDBurn.dll.html
and let me know whether it helps. Just replace you hpCDBurn.dll in the MediaMonkey directory by the new one from the link.

[BluBear]

Peter,
please give a try with this hpCDBurn.dll : http://rapidshare.com/files/279887471/hpCDBurn.dll.html
and let me know whether it helps. Just replace you hpCDBurn.dll in the MediaMonkey directory by the new one from the link.

Thank you, Ludek!
Tried it, and it does work. Ripped three CD's in a row, including my previous test candidate - all without a hitch and at breakneck speed. The previous test CD now comes in at 2:05 minutes for the entire operation.
I captured the entire test with a log and can submit, if requested.

Well done.