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

[Ludek]

The other idea I have looking at the changes between build 1488 and 1489 is issue
http://www.ventismedia.com/mantis/view.php?id=9326

Do you have x64 platform?
Could you try the following test?
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

[MMuser2011]

If I try to rip the tracks as WAV (in v1489 and higher) I get bigger files, but completely empty...The MM4-error remains the same as you can see in the printscreen above.
In v1488 I can rip to wav without any problem, they play fine.

Ups, I have seen your additional remark. YES, I have Win7 64bit Ultimate.
I try to patch MM4 as you suggested. Feedback follows soon.

[Ludek]

OK, Do you have x64 platform?
Could you try the test described in my last note above?

[MMuser2011]

I have downloaded the tool to the same directory as MediaMonkey.exe (v1488). I have checked again: v1488 rips to wav or mp3 without any problem. Then I started the '4gb_patch.exe', opened MediaMonkey.exe and got the message "Executable successfully patched!" (A backup of the original MediaMonkey.exe was created.)
The strange thing: There is no difference between the patched and the backuped file. They are identical (compared with Notepad++-Compare and with WinMerge).
The result is not surprising for me: Rip (still) works fine with the so-called patched MediaMonkey.exe. Should there not be a difference in the two *.exe-files?

[Ludek]

Strange, in my case the patched (MediaMonkey.exe) and orig (MediaMonkey.exe.backup) have both the same size, but the content is different, confirmed by using Total Commander and menu Files -> Compare by content. Are you sure that the EXEs are really same in your case? I could path the 1488 exe for you, which 1488 build you uses - regular or debug?

[MMuser2011]

I'm as sure as two compare programs tell it to me.
I use the debug-versions v1488 and v1496. It would be great, if you could tell me a possibility to DL it and try it again with the patched one.

[Ludek]

Here is patched EXE from 1488 debug: http://www.mediafire.com/?aw7sec4xbec57cu

[MMuser2011]

Thank you very much!
Result: Ripping a CD to mp3/wav works still fine with your patched v1488*.exe

BTW, if I compare it with Win7-Commandline-tool COMP

Code: Select all

Vergleichen von MediaMonkeyv1488Original.exe und MediaMonkeyV1488patched.exe...
Unterschied festgestellt bei OFFSET 116
Datei1 = 8F
Datei2 = AF
Unterschied festgestellt bei OFFSET 158
Datei1 = 64
Datei2 = 84

Unfortunately, this eliminates http://www.ventismedia.com/mantis/view.php?id=9326, right?

In the meantime, I learned how to use the CFF-Explorer to manipulate the File Header and the checkbox "App can handle > 2GB address space". Disabling this setting in the (not ripping) v1489 has no impact. I think, the persistent bug must have another reason?

[Ludek]

OK, so if you copy EXE from build 1489 into 1488 folder and run it, does it fail then?

9326 is not completely eliminated yet, because as we can see it seems to depend on which system the patch is applied, as you told that on your system the EXE hasn't changed by the patch, I will ask our dev that creates builds to patch the exe. Just please confirm that EXE from 1489 fails in 1488 folder.

[MMuser2011]

You will hear a soon as possible. Give me an hour or so .-)

[MMuser2011]

Just please confirm that EXE from 1489 fails in 1488 folder.

v1489 DOES NOT FAIL(!) to rip in a v1488 folder. The same is true for v1496. Both versions of MediaMonkey.exe DOES NOT FAIL if they are the only changed files in a directory based on v1488-installation.
Now I'm confused

And just to be sure: The version information in MM4 with "Help/About" shows always 1488 if I only change the MediaMonkey.exe, right? The v1489 or v1496 would be displayed from other parts then the MediaMonkey.exe?

[Ludek]

Hmmm, so the problem is not in the main exe, but in a plugin.

Watching SVN changes between build 1488 and 1489 onlz the following were changed:
Plugins/d_iPhone.dll
Plugins/d_iPod.dll
Plugins/f_video.dll
MediaMonkeyVHelper.exe

they are related to video / portable devices hadnling, but it seems that they somehow influence the ripping?? So please try to copy them (from 1489) into 1488 folder to see which one it causes. I wonder which one it could be as it still seems to be very strange.

Thank you!

[MMuser2011]

Unfortunately, none of this 4 files (or any combination I tried) seems to be the reason...

Which files could be related to the ripping process? I could try to swap them between 1488 and 1489?

[Ludek]

To the riping process should be related only PrimoBurner.dll and hpCDBurn.dll but there were no changes in these DLLs between build 1488 and 1489, but give a try for sure.

Nevertheless it would be valuable if you could find the difference.
BTW are you sure that 1489 and 1488 are both debug builds and regular installs or both portable installs?

[MMuser2011]

I only use the debug-builds for this comparison.

What about the "MediaMonkey (non-skinned).exe"? If I change this file back to v1488 in a v1489-folder, the rip works fine.

Addition: In a v1496-folder I have only to change the "MediaMonkey (non-skinned).exe" to the v1488-version and the rip works without any problems. Is this a strange coincidence?