I've tried now different PCs one being the HP nx8220 laptop I'm typing this on and LAME 3.97 seems to crash repeatedly with VBR 192. I'm ripping CAMEL's I can see your house from here with EAC. It stops in the first track Wait.

Overclocking is not really possible with this laptop.

What are the alternatives to LAME?

More than 180,000 conversions with LAME 3.97, and I can't recall a single crash. I'd say your problem lies elsewhere.

where?

tried this with a the mentioned HP nx8220 laptop and a Shuttle Reflection XPC. Common factor being EAC and Windows XPSP2.

But thanks for the message (please do look at others reporting frequent crashes with 3.97)

Laptops are known to overheat easy when subjected to high processor loads, I know I've had a couple that could not do extended encodes.

LAME 3.98b6 would be a good replacement for 3.97.

I'm quite sure that LAME does not crash. One common problem is, you're trying to feed in some ID3 genre, which is not a valid ID3v1 genre. In this case, 3.98 will help you, or you can add "--ignore-tag-errors" to your command line.

Thanks robert.
So this would mean to add these as additional parameters to EAC?




So not really. LAME crashed again. I would love to have someone tell me where to get diagnostic information that could possible help someone to fix this.

this is on my screen right now:

LAME version 4.0 (alpha 14, May 25 2006 12:48:18) (http://www.mp3dev.org/)

warning: alpha versions should be used for testing only

Using MDCT filter
Lowpass filter, transition band: 17461 Hz - 17548 Hz
Encoding F:\@Shared\Shared Music\Camel\I Can See Your House From Here\0tmp1!542.
wav
to F:\@Shared\Shared Music\Camel\I Can See Your House From Here\0tmp1!542.
mp3
Encoding as 44.1 kHz VBR(q=4) j-stereo MPEG-1 Layer III (ca. 10x) qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
6969/11623 (60%)| 0:07/ 0:12| 0:07/ 0:12| 24.254x| 0:05
192 [5667] %%%%%%%%%%%%%%%%%%%%%%********************************************
224 [ 934] %%%%%%%****
256 [ 316] %%**
320 [ 51] %
---------------------------------------------02:01-----------------------------
kbps LR MS % long switch short %
200.1 37.2 62.8 96.7 2.2 1.1

Turns out you are not using LAME 3.97.

Also, could you be more specific about how it crashes? Do you get any error messages?

Try using the current version of lame, not some ancient alpha that wasn't made for encoding.

You are using some unofficial LAME 4 alpha build, not LAME 3.97 as you were telling above. You should replace it with some LAME 3 version.

Splitting ripping and converting might give some hints:

1) Have you tried to rip to wav (EAC menu Action>Copy>Uncompressed)? Does that work OK?

2) Have you tried to just convert an existing wav file to mp3 for example through system commandline (DOS Window) or with some frontend? What happens?

Yes that works, thanks for aksing alexxander. FLAC also works fine. Only the LAME encoder seems to cause trouble

For mp3? Well there are lots in theory I guess but none worth using I use the nero aac codec as my replacement but that's prolly not an option for you...

like others in this thread, I've *NEVER* experienced a crash with LAME that was a direct result of it. There may be some other instability in your machine.

Please let me know what is "official". Where would I locate an official LAME build?



Thanks for pointing that out, frozenspeed. My machine is just as stable as any Windows XP SP2 machine ;-) and I have no problems using other programs

http://wiki.hydrogenaudio.org/index.php?ti...wnload_page#MP3

http://lame.cvs.sourceforge.net/*checkout*...ml/history.html

I think here is a good place.

http://www.rarewares.org/mp3-lame-bundle.php


Doh! We replied three in a row at the same minute

Just to eliminate any doubt because I'm not sure reading your answer:

Have you tried option 2) (converting through commandline or frontend)?

And: Are you now using v3.97 or 3.98b6 as suggested?

I was using 3.97 and used lame-3.98b6_2008021306 (LAME 32bits version 3.98 (beta 6, Feb 13 2008) (http://www.mp3dev.org/)) with similar result.
I've ripped to .wav file and started lame as : "C:\Program Files\lame\lame.exe" "01. Wait.wav".

It crashes with this:

F:\@Shared\Shared Music\Camel\I Can See Your House From Here>"C:\Program Files\l
LAME 3.98 (beta 6, Feb 13 2008) 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding 01. Wait.wav to 01. Wait.wav.mp3
Encoding as 44.1 kHz 128 kbps j-stereo MPEG-1 Layer III (11x) qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
3900/11623 (34%)| 0:09/ 0:26| 0:09/ 0:26| 11.281x| 0:17
-------------------------03:21-------------------------------------------------
kbps LR MS % long switch short %
128.0 51.0 49.0 97.8 1.3 0.8

or with this:

F:\@Shared\Shared Music\Camel\I Can See Your House From Here>"C:\Program Files\lame\lame.exe" "01. Wait.wav"
LAME 3.98 (beta 6, Feb 13 2008) 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding 01. Wait.wav to 01. Wait.wav.mp3
Encoding as 44.1 kHz 128 kbps j-stereo MPEG-1 Layer III (11x) qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
8300/11623 (71%)| 0:19/ 0:27| 0:20/ 0:28| 11.132x| 0:08
-----------------------------------------------------01:26---------------------
kbps LR MS % long switch short %
128.0 39.0 61.0 98.1 1.2 0.7 Assertion failed: p > 0, file libmp3lame/psymodel.c, line 1242

abnormal program termination

F:\@Shared\Shared Music\Camel\I Can See Your House From Here>

or this:

F:\@Shared\Shared Music\Camel\I Can See Your House From Here>"C:\Program Files\lame\lame.exe" "01. Wait.wav"
LAME 3.98 (beta 6, Feb 13 2008) 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 16538 Hz - 17071 Hz
Encoding 01. Wait.wav to 01. Wait.wav.mp3
Encoding as 44.1 kHz 128 kbps j-stereo MPEG-1 Layer III (11x) qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
9500/11623 (82%)| 0:22/ 0:27| 0:22/ 0:26| 11.063x| 0:04
-------------------------------------------------------------00:55-------------
kbps LR MS % long switch short %
128.0 37.3 62.7 98.2 1.1 0.7

Moderadion: Extra quotations removed

You could try LAME 3.90.3 at --alt-preset standard (which is about 192 VBR) and see if that works or use a command line fhg mp3 encoder which has a offical download link someware on the net for the fhg surround sound which can do VBR (but does not use 320kbps frames) and supports SMB. ATM am thinking EAC could is likely to be causing the crashes after the drive is not in use while encoding or something is making the ripped WAV files courrpt. Make sure you did not change the Waveform settings, which should be disabled when EAC is configured to external encoder.

Have you tried the 12 March compile of 3.98beta6?

..which, by incident is the version I'm using.




ehrm, thanks /mnt .

I was using 3.97. "official" does not seem to mean very much, more like a "it works for me". I would not understand how to change the Waveform settings so probably I have not changed these (right?)

OK, first, I'm still seeing various versions in your reports so I'm not clear: Are you using 3.97. Use 3.97, and don't work with alphas, betas or outdated versions. Stick with the current version, so we can diagnose the problem in a straightforward way. From the sounds of things, an alpha, beta or anything else isn't for you anyway.

Second, but closely related, let's steer away from advice that is not 3.97-specific. Rolling him back or ahead is only making matters worse and just confusing people -- especially me!

I would also recommend going with -V 2 --vbr-new instead of 192kbps VBR. 192kbps VBR sounds like it is one of those mp3 presets built into EAC. Instead you should either select User Defined Encoder or use the Lame mp3 option but set the bitrate to 128kbps and use the command line of -V 2 --vbr-new. -V 2 should come out to around 190kbps VBR but it depends on the complexity of the music. You should always use the presets when encoding VBR mp3s. Those presets (the various -V values) were designed to give you a constant quality level, not a constant bitrate level (as does the 192kbps VBR setting in EAC does).

You should stick to John33's binary, I'd never experience any crash or problems with his work.

http://www.rarewares.org

I encode within foobar and also have random crashes. But only on my old AMD machine that has big temperature problems. I never had any issues on my cool Core2Duo machine. So I am sure it must have to do something with the temperature, especially when you are on a laptop.

Alex

These crashes are 99% hardware related. Run memtest86 & a hard drive diagnostic.

My guess that the hard drive on the notebook could have bad blocks, which could have corroupt the WAV files while ripping. And also it cold be possible that EAC does not like the drive going idle when encoding the track with LAME. I have been using LAME 3.97 at V 2 --vbr-new for 2 years now and never had a crash on it, I used it on my old comp and my new one that I have built and hell i used it on Vista (a god awful OS) aswell and did not any problems with it at all.

Thanks csiron,

Let's just stay with 3.97 and exclude the more exotic problems. I'm not overclocking nor helium cooling my laptop nor planning to do either. :-)

I've installed EAC v0.99 prebata 1 on a HP nx8220 laptop. Ripping to a WAV file does not cause any problem. Neither does ripping to FLAC file. So we savely can exclude CD drive compatibility issues.

I have downloaded the wintel binaries from http://www.rarewares.org/mp3-lame-bundle.php version 3.97 (with Metaproducts download manager version 1.7) and expanded it (using Directory Opus compressed file handler version 8.2.2.5 Unicode) to a local folder.

I'm ripping the R.E.M. Jukebox CD with the following result:

LAME 3.97 32bits (http://www.mp3dev.org/)
CPU features: MMX (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 17249 Hz - 17782 Hz
Encoding F:\@Shared\Shared Music\Various Artists\REM Jukebox\0tmp1!542.wav
to F:\@Shared\Shared Music\Various Artists\REM Jukebox\0tmp1!542.mp3
Encoding as 44.1 kHz VBR(q=4) j-stereo MPEG-1 Layer III (ca. 10x) qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
200/5699 ( 4%)| 0:00/ 0:19| 0:00/ 0:19| 7.7745x| 0:18
32 [ 1] *
192 [193] %%%*****************************************************************
224 [ 6] %%*
256 [ 0]
320 [ 0]
---02:23----------------------------------------------------------------------
kbps LR MS % long switch short %
192.2 5.5 94.5 96.0 2.0 2.0






memtest revealed a healthy system, but thanks for the hint shadowking.




Thanks /mnt. having bad blocks or the laptop going to "sleep" will most probably thward the ripping and compressing process. Creating and playing uncompressed files does not pose any problems, though. As the batteries of this laptop have been gone long and I therefor always work on mains and switched off any power management this can be savely excluded as the causing a problem.

What about CPU stability?
You can try to run SuperPi (http://www.xtremesystems.com/pi/) and calculate 32M digits.
There's also test in WinRAR (http://www.rarlab.com/). Just run it and press Alt+B.

-------------

+ 000h 00m 00.359s
+ 000h 00m 00.780s

No errors found on benchmark winRAR


...ohw hang on you said 32M. ... superPi seems to be buggy as well and crashes midway (after some memory allocation) (can't people write any quality software anymore these days, <sigh>)

But this does not help me very much. I means that both superPI and lame v 3.97 are not very reliable or use a library that is.

If your system is failing on SuperPi, I can asure you it's your system, not SuperPi. What you really need to run to assure your system is stable is Orthos with the blend setting. I run three C2D systems all 25%, or more, overclocked, orthos stable, and Lame never crashes.

It certainly sounds like a hardware problem to me, probably a memory controller related, over a certain range of blocks. One of the problems with programs like memtest for laptops is that they don't stress the CPU along with the RAM, so don't show many classes of mechanical (disconnect on heating) and power problems. SuperPI works both pretty hard, so it often sees problems that memtest86 misses. I would try prime95, one thread per core.

While I wouldn't discount a bug in both superpi and LAME, superpi is used extremely widely and it seems as though a hardware error is more likely.

Try Monkeys audio MAC.exe - its will probably crash harder than lame if your hardware is flakey.

Are you sure you specified a valid genre if you let lame do the tagging?

It would not have gotten even partway into the conversion if it had not understood the genre. It would have simply opened, displayed an error message, and then closed immediately.

I have been using various versions of LAME for over 6 years, never a crash on any laptop or desktop for me. Past threads like this have resulted in finding hardware issues.

Prime95 is great for testing system stability. It hits memory and CPU hard. I do not recall it covering the hard disk.

http://www.mersenne.org/freesoft.htm

Good luck with it.

I don't think any more testing needs to be done. Lame 3.97 crashed which strongly indicates a hardware problem, and that was corroborated when SuperPi also crashed.

There is no doubt, something is wrong with that computer.

everytime the power goes out over here lame crashes.

what a piece of crap software...

... ignorance is a blessing at times ...


it really sounds like a temperature issue to me, most likely your CPU is overheating or maybe even a fan is failing

go and grab Everest to monitor your temps and fan RPMs and re-run SuperPI

if it keeps crashing, you should consider reading this guide
http://radified.com/Articles/stability_testing.htm

Regards,
Maggi

But if Everest crashes on him he'll blame that too...

uh oh ...

We haven't heard from "th00ht" in some time. Maybe his computer is down? Those dam unreliable OS's!