Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Ton]

Yesterday I tried to rip and encode a cd, using an external (Lame) encoder and the --alt-preset standard.
Every track was ripped and encoded in succession but when I looked in the folder that I use for the output files I missed 2 tracks. It appeared that they still were in the tem. folder. It WERE mp3 files, but in the filename there was the addition .wave.
I could cut/copy and paste them to the appropiate folder so everything was o.k. , but I don't understand why this happened. Has anyone a clue ?
Btw this is the first time I saw this happening.

[Matt]

We'll try to reproduce.

And maybe we should make the MP3 encoder accept custom command lines.  That way you'd get on-the-fly encoding.

[Ton]

Thanks Matt. I will await further info.
Btw,maybe a dumb assumption, but could it have something to do with  YADB ? The cd I tried to rip showed up wrong. It is a double cd and the second one showed up with the data from the first one and the data of the first one couldn't be found.

[Ton]

Because I haven't ripped cd's the last weeks I almost forgot my post.
Yesterday and today I tried to rip again and I had the same problem with all the cd's. A number of tracks stayed in the temp folder with .wav extension, although it were mp3's.
I didn't see a further reply from Matt or anyone else.
Although I can cut and paste the tracks it's a little annoying.
I hope someone can help me as yet.

[Ton]

Doesn't anyone know a solution ?
And why doesn't Matt give further information ?

[KingSparta]

maybe if the user hits cancel it don't erease them, i think i remember something like that.

[JohnT]

Is there anything unusual about the track names? Perhaps there's an issue with Unicode characters. To test this, try all track names with plain vanilla english names like "track 1", "track 2", etc.
Or, filename length problem? What's your file naming scheme set to?

[xen-uno]

Could be that they haven't been able to reproduce...and no other user has verified that there is a problem. Could be something funky with your setup.

10^-27

[Ton]

Thanks for the replies.
JohnT: I didn't notice anything unusual with the track names, but next time it happens I will try to rerip with the suggested names, like track 1 etc.
My naming schedule is:
Directory rule: [Album] and
Filename Rule: [Track#][Name].
The "strange" thing is that only a few tracks stay in the temp folder with wav. extension, although it are mp3's.

[JohnT]

Thanks for the replies.
JohnT: I didn't notice anything unusual with the track names, but next time it happens I will try to rerip with the suggested names, like track 1 etc.
My naming schedule is:
Directory rule: [Album] and
Filename Rule: [Track#][Name].
The "strange" thing is that only a few tracks stay in the temp folder with wav. extension, although it are mp3's.

I can't reproduce the problem here. Try getting some more specific info the next time it happens, such as what the CD is, the track titles that failed, do the same ones fail every time for that CD or is it random, etc.

[Ton]

Tonight I had the problem again. For what it's worth, I was ripping the cd "Sao Vicente Di Longe" by Cesaria Evora, a cd with 15 tracks from which track 14 ( "Fada") stayed in the Temp folder. When I ripped this cd again, the same track stayed again in the Temp folder.However I noticed one thing in the DOS screen that appears when, after ripping, the track is encoded by the external Lame 3.90.3 encoder, using --alt-preset standard. Normally, when all goes right, it says "Encoding E/MyMusic/Temp/tracknr+title.wav to E/MyMusic/CDRips/tracknr+title.mp3". With the "culprit" track however I read "Encoding E/MyMusic/Temp/tracknr+title.wav to E/MyMusic/Temp/tracknr+title.wav.mp3". So the track was encoded TO the Temp folder instead of the CDRips folder and the extension was .wav.mp3 instead of .mp3.
Btw, when I ripped the same cd again, but now with the built-in encoder using VBR and High Quality everything went right for all the tracks.

[Ton]

Bump

[JimH]

Ton,
We don't know what the problem is.  It could be a bug in the Lame encoder you're using.  Ripping to other formats might prove or disprove that theory.

Jim

[Ton]

Thanks Jim for your reply. Do you mean with another version of the Lame encoder or try another preset ?

[JimH]

You've been using the Lame external encoder.  Try the Media Center Lame plug-in or any other internal plug-ins.  If you ripped and encoded to APE, for example, you could later convert to MP3 without losing anything.

[Alex B]

I have used external lame.exe for years with this command line: %IN %OUT --alt-preset extreme. "Encoder supports long file names" is enabled. My standard paths are these: Temp E:\Temp\, Base D:\Music\, Directory rule [Artist]\[Album], Filename rule [Track #] - [Name]. I have never had that problem.

Currently my external LAME encoder is from the 3.90.3 package from www.rarewares.org.

I have also replaced the lame.exe in MC plugins directory with newer LAME 3.96.1. (I updated MC's internal encoder this way). I use that with the next command line: --preset extreme --noreplaygain. (Yes, it is possible. Just use Custom Quality and write your command line in the Custom Options under Advanced tab). Also that works flawlessly. Lame 3.96.1 is twice as fast as 3.90.3. I use that when I am in a hurry.