Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: EAC 1.0beta 3 crash upon log file creation (Read 4673 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

EAC 1.0beta 3 crash upon log file creation

Hi! Although I have been a regular user of EAC, I am new to this forum. Thus, I apologise for any stupidities that I may commit!

I've been using EAC 09beta4 for years but recently decided to upgrade to 1.0beta3. Of course, I ran into an issue that, after days of trying and searching the web, I have not been able to resolve.

The issue is the following: after ripping and compressing, the log shows that everything went OK and that no errors were produced. However, when I try to save the log file, EAC crashes with the error "unhandled exception 02F39F09 -> C000001D" (sometimes 02F29F09). Apart from the fact that this drives me crazy, it prevents me from documenting a successful rip.

When EAC crashes, a log file is written but it is empty.

The details:
- I run Windows XP (in french, the same machine as before; fully updated)
- about 1 in 10 times, I can save the log file without EAC crashing; after about 40 trials I have not identified an obvious cause
- changing the optical drive does not make a difference
- gap detection and writing a CUE file or not, does not make a difference
- using the internal aspi interface or wnaspi32 as external does not make a difference
- uninstalling EAC and deleting the registry key, followed by a fresh install does not make a difference
- compressing using LAME (3.90.3 or 3.99.2.5) or FLAC 1.2.1b does not make a difference
- writing CRC values or not does not make a difference
- writing the log file to the folder used to rip or not (or for that matter a different HDD, or the desktop) does not make a difference
- automatically writing the log file or manually doing so after the rip has completed, does not make a difference
- this behaviour is seen with multiple, original CD's (no exceptions)

I could copy-and-paste everything but that does not seem to make sense. Let me know what would be of help.

One final bit of unexpected behaviour; when I manually try to write the log file to the pre-specified folder used to rip (D:\EAC\Ripping) with the output file pre-specified as "%albumartist% - %albumtitle%\%tracknr2% - %title%", hitting Save actually moves the Explorer into the %albumartist% - %albumtitle% folder rather than saving the %albumartist% - %albumtitle%.log file.

I've looked hard but cannot find the solution. Thanks for your help!

EAC 1.0beta 3 crash upon log file creation

Reply #1
Is option EAC Options->Tools->Append checksum to status report enabled?
If it is enabled, disable it and try again.

EAC 1.0beta 3 crash upon log file creation

Reply #2
Yep, check the 'Append checksum to status report' flag and change the setting.
Old processors (like AMD Barton step for exemple) can't create the CRC at the bottom of log.

EAC 1.0beta 3 crash upon log file creation

Reply #3
Thanks! I did as you told me and .... no problems with 3 consecutive CD rips.

I messed around for 5 days and you manage to fix it in minutes! Great help!

I'll run a few more and let you know.

EAC 1.0beta 3 crash upon log file creation

Reply #4
Hi Rollin and ThePampers,

Thanks a million. I've now ripped more than 10 CD's and the problem has gone.

You're great!

EAC 1.0beta 3 crash upon log file creation

Reply #5
Old processors (like AMD Barton step for exemple) can't create the CRC at the bottom of log.
This is something interesting I’ve never heard about. I presume it’s due to the calculation utilising some newer added set of instructions (SSE, etc.) that these CPUs don’t have?