Can't rip CDs anymore with 4.0.5.1496 and 'secure read'

[MMuser2011]

I believe, I found it!!

If I modify the "MediaMonkey (non-skinned).exe" v1489 with the "CFF Explorer.exe" in the section 'File Header' and DISABLE the checkbox "App can handle > 2GB address space" I can rip my CDs with the version 1489. The same is true for the newest v1496. I just have to modify this 4GB-Patch-flag and the rip works without any problem with the 'secure read' mode.

You have been right with

Patch the MediaMonkey.exe from the last working build (1488) by using these steps: http://www.ntcore.com/4gb_patch.php and let me know whether it fails to rip after applying the patch? It would confirm that it is caused by the issue #9326

Only with the little adjustment, that it looks like the file "MediaMonkey (non-skinned).exe" is relevant for the rip process.

What do you think?

[Ludek]

Hmm, you are using the non-skinned version, i.e. you have checked the non-default settings in Tools->Options->Skin->[x] Override Windows System Theme (requires restart). It is causing that MediaMonkey (non-skinned).exe is used instead of the MediaMonkey.exe when running.

So please try to uncheck the checkbox and then MediaMonkey.exe will be used. I guess that then the patched EXE that I post you wouldn't work in 1488 folder?

[Ludek]

I overlooked your last post above, so it is definetly caused by the http://www.ventismedia.com/mantis/view.php?id=9326

Thank you so much for your time when sorting this issue!

[rusty]

Hi MMuser2012,

I've tried to replicate this issue, but am having no success:

Testing by ripping CDs to flac on Win7 x64
1) Secure mode enabled / verification disabled / skinned
2) Secure mode enabled / verification enabled / skinned
3) Secure mode enabled / verification disabled / unskinned
4) Secure mode enabled / verification enabled / unskinned

In all cases, I'm using the 'normal' build (i.e. non-debug). Can you think of anything particular to your environment that may be triggering the issue? btw, how much ram is installed on your system?

Thanks.

-Rusty

[Ludek]

Hi I found something specific to secure read mode that could cause the issue.

Could you please download following hpCDburn.dll: http://www.mediafire.com/?hep1cc309ksxcfv , copy it over your existing hpCDBurn.dll and give a try with secure mode, does it still fail with this hpCDBurn.dll ?

[MMuser2011]

Hi rusty

"Particular"? Hmm, maybe that I use a german Win7 64bit?

Code: Select all

Betriebssystemname	Microsoft Windows 7 Ultimate
Version	6.1.7601 Service Pack 1 Build 7601
Systemtyp	x64-basierter PC
Prozessor	Intel(R) Core(TM) i7 CPU 965  @ 3.20GHz, 3201 MHz, 4 Kern(e), 8 logische(r) Prozessor(en)
SMBIOS-Version	2.5
Windows-Verzeichnis	C:\Windows
Systemverzeichnis	C:\Windows\system32
Startgerät	\Device\HarddiskVolume2
Hardwareabstraktionsebene	Version = "6.1.7601.17514"
Zeitzone	Mitteleuropäische Sommerzeit
Installierter physikalischer Speicher (RAM)	12.0 GB
Gesamter realer Speicher	12.0 GB
Verfügbarer realer Speicher	8.01 GB
Gesamter virtueller Speicher	15.9 GB
Verfügbarer virtueller Speicher	11.7 GB
Größe der Auslagerungsdatei	3.95 GB

Until MediaMonkey v1488 ripping a CD worked without any problems. The problems with the 'secure read mode' started with 1489. I can reproduce this anytime - without any hardware changes to the system.

Do we have any chance to produce a log file from the ripping process itself (hpCDBurn.dll, PrimoBurner.dll)?
As I wrote to Ludek: The only thing I need to change in v1489 or v1496 is the 4GB memory flag. Can we trace this?

[MMuser2011]

Could you please download following hpCDburn.dll: http://www.mediafire.com/?hep1cc309ksxcfv , copy it over your existing hpCDBurn.dll and give a try with secure mode, does it still fail with this hpCDBurn.dll ?

I try it!

[MMuser2011]

@Ludek: Sorry, your 293kb hpCDBurn.dll does not work with a v1489-debug version installed with 'secure read mode'. (Ripping works with this DLL in 'standard mode').
If I apply the 2GB-Memory-Patch to the 'MediaMonkey (non-skinned).exe' it works too in 'secure read mode' with your bigger hpCDBurn.dll

[Ludek]

OK, please give one more try with this one: http://www.mediafire.com/?3nnqh65wr6a06a3
Thank you.

[MMuser2011]

BINGO!
Your last hpCDBurn.dll-version WORKS FINE with the v1489-debug-version and without any modification on the *.exe for 'secure read mode'!

What is the difference? What have you found?

[Ludek]

The difference is just size of read buffer, if it is the same as in case of standerd read (63 KB) then it works fine, but if it is 512 KB or bigger (like in case of secure read) then it fails :-/ Secure read needs bigger buffers in order to flush internal device cache when performing double reading, therefore the buffer needs to be equal to internal device cache capacity.

[MMuser2011]

Sounds to me a little bit like a scene from the TV-show "Bones", when Dr. Temperance 'Bones' Brennan talks with latin anatomical words about single bones of a skeleton to her partner FBI Special Agent Seeley Booth.

Thank you very much for your support and patience!

[Ludek]

I also thank you very much for your patience, fortunatelly we were able to figure it out, it will be fixed as http://www.ventismedia.com/mantis/view.php?id=9421

[Ava42]

OK, please give one more try with this one: http://www.mediafire.com/?3nnqh65wr6a06a3
Thank you.

I was having the same issues and this fixed it for me too.

Thanks!