Well, I never thought it would come,
but I am about 2 days away from re encoding 10,000 mp3's with --alt-preset standard.

<kickingmyself>
I now notice that playback of said mp3's on my empeg is not gapless,
I wish I'd have asked this here before.
<kickingmyself>

... but here' goes.

How can I encode with EAC & LAME --alt-preset standard so that I get gapless playback on my empeg ?

There was another thread on this topic a while back. Getting the command line parameters right for LAME-gapless is very tricky.

The only way I was ever able to do it was to rip everything to wave files and then hand-run lame with multiple track numbers on the command line, all as one huge batch. Dunno if EAC even allows this.

what would you use on commandline say to encode: somewavfile.wav gapless ?

I am thinking LAME --alt-preset standard --nogap somewavfile.wav somewavfile.mp3

not sure that this is correct syntax, nor am I sure that --nogap works with --alt-preset standard...

Any Ideas ?

This is why having ogg (gapless) playback on the empeg would be nice.

Sean

The only way I was ever able to get it to work was this way:

lame --nogap track01.wav track02.wav track03.wav

I don't think you can combine alt-preset with --nogap.

Does anyone have a link to that other thread where they talked about how the command line parameters worked?

I don't use LAME so I'm not sure of it's workings. But if EAC can ripp and LAME can encode at CBR with --alt-preset standard all tracks as a single, gapless mp3 file, you could always use MP3 Trackmaker to split it up after encoding.


Regards,
Aragon

... and then run into the problem where splitting an MP3 file breaks the bit reservior... we've already discussed this to death....

Yes, we have. I cannot vouch for --alt-preset standard, but I am currently using EAC and LAME to create my mp3s.

For the most part, I've had to wait until EAC finishes ripping and then run LAME separately. And yes, you must list each of the files in the LAME commandline, in the appropriate order, with 2 spaces between each file. LAME will automatically save them as mp3s with a matching filename.

The other way is to have EAC start LAME after the first track is ripped. Now in order to get gapless encoding to work, that instance of LAME has to remain running while EAC is ripping, and you can have no more than one instance of LAME running. If I were at home right now I could open up EAC and tell you what option this is, and where to find it.

There is a problem with the second method, though. As an example, if LAME finishes encoding 01.wav to 01.mp3 before EAC finishes saving 02.wav, then LAME will close and the gapless encoding will be lost. To use the second method safely, you would have to optimize EAC's ripping for speed instead of error correction.

When I get home I'll dig up the name of the option in EAC, and also list my LAME commandline. Currently, I manually run LAME and paste in the commandline as soon as EAC has finished ripping; I don't take any chances.

I'll leave the side comments out
but lame.exe --alt-preset standard --nogap 01.wav 02.wav 03.wav seems to be working as lame is picking up the presents of the nogap parameter and it is encoding at it usual --preset slow pace (both with single spaces and double spaces)
I can't confirm as the only CD I have handy would not really show up the use of nogap too well.

anyway in the mean time I'll see if i can put together a script or batch file to make it a bit easier then the writting the full command line everytime.

PS what made you change over?

In my experience, two filenames listed in the LAME command line with one space between them tend to make the first file get saved as the second file. i.e., lame 01.wav(space)02.wav would generate an mp3 for the first file named 02.wav, and then it would go on to encode 02.wav as 02.mp3. The result would be 02.wav, which is really an mp3 of 01.wav, and 02.mp3, which is also an mp3 of 01.wav, with a different name. That is why I specified two spaces between filenames when using --nogap.

Anyway, I'm home now, and I've had a chance to look up the option in EAC that I mentioned earlier. Choose EAC Options... from the EAC menu, and then go over to the Tools tab. The option to enable is On extraction, start external compressors queued in the background. This will run your encoder (LAME in my case) as soon as the first track has finished ripping. The option comes set to a default of one instance of your encoder. Now, assuming the ripping process can keep up with LAME, you can use this to encode gapless mp3s during extraction.

I have had some trouble with this - mainly scratched CDs that EAC reads slower to make sure that it has correctly extracted the audio. As I said before, if LAME finishes a file before EAC has the next one ready... then a gap will exist between those two files when played back in order.

Now in order to get gapless encoding to work, that instance of LAME has to remain running while EAC is ripping, and you can have no more than one instance of LAME running.

No. For gapless encoding to work, all the files must be specified on the same Lame command line. EAC can not do this, it always runs Lame individually for each track.

Incidentally, Lame 3.91 disables VBR tags if --nogap is given. This is unnecessary, and should be commented out (in frontend/main.c) if you'll be using your gapless files on an Empeg.

Peter

I just explained in several posts that you can force EAC to only run one instance of LAME, which would make --nogap work. Don't tell me I'm wrong when I've already tested it and watched it work. When you use the option I specified in my earlier thread, it DOES work, as long as LAME doesn't finish encoding the current file before EAC has the next one ready.

I no longer use this method because I have quite a few CDs that EAC cannot extract fast enough to keep up with LAME. But if you have a mint condition CD, you should be able to use that option, as long as your drive is fast enough.

[Edit:]
Get a CD that's in good condition and optimize EAC for speed. Then turn on the option I mentioned and have LAME setup for --nogap. As long as EAC stays at least one whole file ahead of LAME, it will work.

HeHe,
I don't really know why a changed over,
I think the bottom line is that --a-p s gave me a bit smaller file size that the string I was using, and I compared them both on my empeg, and I couldn't tell the difference. Although --a-p s is a h3ll of a lot slower to encode.

I'll see if i can put together a script or batch file
don't you wish you could just

lame *.wav

If you had a batch file named lame.bat, you could, but the --nogap tag wouldn't work unless each file was listed in the commandline. You could do THAT in the batch file, if you wanted to use say, only track numbers for filenames (01.wav 02.wav 03.wav). All you would have to do is have enough of those in the commandline in the batch file to cover your longest CD. On any CD that doesn't have as many tracks as LAME is looking for, LAME will simply give you some form of "file not found" message and end.

[Edit:]
With a batch file setup this way, you wouldn't be typing "lame *.wav", you'd simply be typing lame.bat, or encode.bat, or whatever you name the file.

Incidentally, Lame 3.91 disables VBR tags if --nogap is given. This is unnecessary, and should be commented out (in frontend/main.c) if you'll be using your gapless files on an Empeg.

Let me just clarify that! The current car-player software, even internal builds, always flushes the bit reservoir between tracks even for consecutive tracks from the same album. A future version will not flush the decoder in that case, which should allow true gapless playback, independent of whether a Xing VBR header is present.

Peter

So you're saying that the current method of gapless playback on the empeg, even though it works fine (at least in my case, and currently I'm still running 1.03), is not true gapless playback?

So you're saying that the current method of gapless playback on the empeg, even though it works fine (at least in my case, and currently I'm still running 1.03), is not true gapless playback?

It's possible on some -- maybe most -- transitions to get lucky, especially if there's nothing hard-to-encode spanning the transition. But in a future version the car-player software will (hopefully) get it correct in every case automatically.

Peter

But this will still require that the file be encoded with the --nogap option, correct?

[Edit:]
Apparently LAME does such a good job with --nogap that I've been "getting lucky" on almost all of my transitions. (I'd say 95%)

I just explained in several posts that you can force EAC to only run one instance of LAME, which would make --nogap work.

That setting, at least in the 0.9beta4 that's the latest EAC I can find, affects how many instances of Lame are run simultaneously (for optimising compression on multi-CPU machines). It does not affect the fact that only one WAV file is passed to each instance of Lame. Under such conditions, Lame cannot do true gapless encoding.

When you use the option I specified in my earlier thread, it DOES work, as long as LAME doesn't finish encoding the current file before EAC has the next one ready.

Such a system is technically feasible, but there is simply no code in Lame that implements anything like it. Once Lame.exe has started up -- once it's started compressing a track, for instance -- EAC has no way of adding further filenames to its command line. And I've checked this by making Lame (edit: not EAC) print the filenames it's been given when it starts: it gets one at a time. It sounds like you've just been lucky.

Peter

But this will still require that the file be encoded with the --nogap option, correct?

Yes. In the non-nogap case, it'll sound just like it does now. In the nogap case, it'll get it exactly right 100% (not 95%) of the time.

Peter

It sounds like you've just been lucky.

I suppose I have. Like I said, I don't use that anymore, because I have several CDs which are just error prone and can't be extracted fast enough. But it just looked to me like LAME could accept more filenames while running, because as long as it was still working on the previous track when EAC sent it the next one, they all came out fine.

Although, this may be of interest: Once the whole process had finished, I had in the folder the source WAVs, the encoded MP3s, and then more mp3s which filenames were of a temp nature (tmp*****.mp3). The desired mp3s were fine, though.

it'll get it exactly right 100% (not 95%) of the time.

I look forward to that.

Incidentally I posted a feature request to the EAC mailing list, and here's the response from Andre Wiethoff:


I don't think that this is really necessary... Either do it manually with razorlame, or use offset correction for compression (and a gap killer on playback). I had never heard that the --nogap will work better than that.


In other words, he doesn't want to do it. He's completely wrong in his argument that doing it manually or using offset correction and a gap killer is a better solution. How should I respond to encourage him to do this? If someone else is on the EAC list, feel free to chime in. My original request was posted on 6/28 and is available at http://groups.yahoo.com/group/eac/message/13842 if you're a member of the EAC list.

Although, this may be of interest: Once the whole process had finished, I had in the folder the source WAVs, the encoded MP3s, and then more mp3s which filenames were of a temp nature (tmp*****.mp3). The desired mp3s were fine, though.

If you give the --nogap option, Lame expects all filenames on its command-line to be input files (as opposed to one input file and one, optional, output file). Especially on Windows, where the file locking semantics are different from those in its Unix homeland, Lame will likely get quite confused if you tell EAC to use the --nogap option.

Peter

Very informative. Thanks, Peter. And I apologize for snapping at you earlier. I was going by the results of my expirement and so didn't even consider the technical aspect of why it shouldn't work.

So, to anyone with a fast enough drive to use my method, remember that if it works, you're lucky, like me!

The current car-player software, even internal builds, always flushes the bit reservoir between tracks even for consecutive tracks from the same album. A future version will not flush the decoder in that case, which should allow true gapless playback

VERY interesting idea. But...

I have tried two different gapless playback plugins for WinAmp, one of which behaved as you just spec'd (don't flush the reservoir).

My hand-trimmed files that sounded good with the "flushing" version, had a burst of static at the transition points with the "non-flushing" version.

Okay, I'll admit that my hand-trimming technique is totally nonstandard, and deserves to get broken by a hypothetical future release of the software. But...

The thing you're talking about implementing sounds like the only time it would work perfectly is when the user has created a single large MP3 and then hand-split it at frame boundaries. It wouldn't help hand-trimmers like me, and it wouldn't help those who encoded their CDs normally. It also wouldn't improve upon the LAME--nogap files because (if I understand it correctly), the reason LAME's method works is because it makes sure the bit reservior is unused at track boundaries.

As mentioned above, a script. Pretty basic.
Runs from the directory that contains the WAVs to be encoded. It creats & executes the command line %CURRENT_DIR%\lame.exe --alt-preset standard --nogap track1.wav track2.wav and so on

Known bugs:
1/ Won't execute LAME correctly when fully compiled. (path issue)
2/ Does not clean-up if user selects cancel. (no reason why)
3/ Crashes if user closes LAME window.

Usage:
1/ Down load and install AutoIt (work around to bug 1).
2/ Place LAME.exe in c:\lame. (edit line 4 to change)
3/ Place script in directory with WAVs to be encoded.
4/ Run. Pray. Then click okay.
5/ And thats it, LAME should now be running.

The script can be opened (and edited) in notepad.
Warning: This script may cause your computer to explode! So run away, run away!

Now that I have spent an hour of my work time on this I must make haste and return to the grind stone.

It also wouldn't improve upon the LAME--nogap files because (if I understand it correctly), the reason LAME's method works is because it makes sure the bit reservior is unused at track boundaries.

It also, crucially, ensures that track boundaries fall at granule boundaries by, if necessary, attaching the last few samples of a track to the front of the next track.

Peter

Riiiiiiight. So your bit-reservoir trick doesn't do any additional help in that case, either, then.

So if I understand this right, then...

- The only time the don't-flush-the-bit-reservoir trick is useful is if I encode an album as a single huge MP3 file and then split it up into individual MP3s at frame boundaries. In that situation, it will play back perfectly, provided I don't shuffle it.

- In almost all other cases, the don't-flush-the-bit-reservior trick is actually damaging and could cause an audible problem at track boundaries.

Am I understanding it right?

it makes sure the bit reservior is unused at track boundaries

OK, I've looked into this a bit more in the Lame sources. It turns out it doesn't make sure the bit reservoir is unused -- it just discards it. So (a) keeping it from track to track in the car-player software doesn't win us anything, and (b) --nogap WAV files (if made all from the same command-line as nature intended) really ought to play back perfectly as it is. I'll do more research, probably with this album.

So you lose a bit reservoir's worth of data on each track transition, but you lose that on seek anyway and it's not always noticeable.

Peter