Alright, I know this has all been talked about before, but I thought I'd bring it up again for no useful purpose.

Since as of 2.0 we supposeldy no longer have to worry about the Empeg adding gaps bewteen songs, we now only have to worry about the gaps that are actually encoded into the music files. Since the wonderful folks at the Motion Picture Experts Group decided that each frame would contain exactly 1152 samples, there's no way to encode MP3 files properly. (Thanks, MPEG. ) The possible solutions I've seen so far include:

1. Use WAV (or other direct PCM encoding) files
   
2. Remove the offending MP3 frames
   
3. Use the gapless option to LAME
   
4. Use Ogg Vorbis files
   
5. Prompt the player to ignore the silence
   

The problems with these solutions are:

1. Using lossless encodings will end up ``wasting'' probably about 80-90% of the hard drive space
   
2. This solution exists in tfabris's GapKiller, but I find that the ``skip'' that results is as annoying as the gap -- perhaps more so.
   
3. As of this post, gapless only works on CBR mp3s
   
4. This would be a great solution, as Ogg Vorbis files don't have the fixed frame sample length problem, but the Empeg does not support it (yet?)
   
5. Another great solution except that the Empeg has no facility for this, either
   

I think that solution 1 is right out for the vast majority of us. Solution 2 can work for some folks and not for others, I'm sure. I would love to use Ogg Vorbis files, but I'm not holding my breath for an implementation to be available really soon. And as for solution 3, I'd personally prefer to use VBR. But there already exists a way to mark the end of silence on an mp3 file in the ID3v2 spec in the ETCO tag (§4.5). Now, I'm pretty sure that ID3 tags are not copied to the Empeg, but some sort of metadata must be, as Title, Artist, etc. are. Maybe there's space to put in a timecode for when to switch to the next track. Of course, all of this cannot be done right now, but it seems to be the most transparent, compact, and technically feasible solution. Unfortunately, I've not even loaded a developer image on my Empeg yet, so I don't know if it's at all actually feasible to do this.

Anyone know if this is remotely reasonable or have further information to add?

There's also the new LAME builds which allow a gapless-encoded MP3.

I haven't had a chance to try them on the new 2.0 player software. Anyone?

Oh yeah. Forgot to mention that. I'll edit my post to include it.

But to expand, the way gapless seems to work (at least with v3.89) is that you have to give LAME multiple input files to encode, it encodes the whole as a stream, and picks the closest frame interval to split the stream into separate MP3 files. I don't mean that it creates one big MP3 first, though. It seems to work fine for CBR files, but with ABR and VBR it seems to end up chopping significant portions off of the end of the MP3s. They may get there soon though.

Note that if you do want to use it, it is not documented at all. You have to hand LAME the `--nogap' option and give it multiple input files to encode. Do not try to give it output filenames. It will use the original filename plus `.mp3'. You should be able to use any of the rest of LAME's options, but, again, ABR and VBR don't work properly. And you have to give it multiple filenames or it doesn't do anything different than it would normally.

I still hear a little bit of a gap, but I don't notice unless I am listening for it. Nogap impoves it either inperceptibly or a tiny bit. Ill try stripping out the id3 tags next and see if that gives me any improvement. I know some decoders have problems with id3v2 since everyone's implementation of it seems to be different. After that, Ill try taking out the vbr header. The new decoder definitely does a better job with files than the xaudio one did.

Sean

The Id3v2 spec is all over the place. It allows for up to 200MB? of metadata, zillions of fields, and is in general a mess. Lames --nogap seems to be working ok for me, is there something im missing? I thought the problems with the vbr header have been fixed. I think we will end up waiting for ogg to be implemented for gapless playback. I think Kit knew someone that was working on this. Any other attempts to get around the mp3 format's weaknesses is an exercise in futility it seems.

Sean

I'd disagree with you as far as the ID3v2 spec goes. I've got some problems with it (namely in the sorting fields), but it seems pretty solid. Is there any reason you wouldn't want to be allowed to have lots of metadata? Or do you have a problem with its implementation?

LAME's nogap with VBR/ABR doesn't work for me. In your prior post, you said that it didn't seem to help, at least not much, so I'm confused. Maybe I'm doing something wrong, though. Basically just ``lame --nogap 1.wav 2.wav 3.wav'', making sure that the input files are in order.

I'd like to have Ogg Vorbis. As far as I know, the only person ``working'' on this is Russell King, the lead of the Linux ARM arm (hah), and it was mentioned only in his diary only a few times.

You are right as far as the usage of the nogap switch. I was doing it wrong. That must be why I couldn't tell much of a difference.
The ID3v2 spec creates a problem because many decoders don't read certain fields, and others apparantly will add silence if there are parts that it can't understand. I have also read that since the ID3v2 tag comes at the beginning of the file, the decoder can't find the VBR header. I personally haven't had a problem with it since all I really use is the empeg for mp3 listening.

One idea that has come up is to let the decoder know exactly what the encoder delay is - i think you mentioned this in your first post. The only problem with that is the encoder would have to know to look for it.

Heres some numbers I got from a post RT made a long time ago.
"
Total encode+decode delay: (These numbers are measured, and not up for debate)

delay (samples)
forward+backward polyphase filterbank transform: 481
forward+backward MDCT transform: 576

Then we can just split them equally between encoder and decoder: 528.5
delay for foward polyphayse+MDCT (used by encoder), 528.5 delay for
backward polyphase+MDCT (used by decoder). To align the psycho
acoustics with the MDCT window, LAME adds exactly 48 samples of
padding for a total encoder delay of 576.5.
"

I also read somewhere that you can set an encoding offset of 2257 in EAC for lame VBR, but i'm not sure that would fix the problem.

I'm saddened to hear that nothing is really going on with ogg, I was hoping that a programmer could code it up fairly quick.


Sean

Where can I get these LAME builds that support the --nogap feature?

I'm using 3.89, and I've read the help that came with that build (lame --longhelp), but it makes no mention of this --nogap feature.

Thx!

Lame 3.89 supports --nogap, but doesn't correctly write VBR headers when it's used. It's not mentioned in the --longhelp, but usage is simple:

lame --nogap {file} {file} ...

Later versions (supporting VBR headers in --nogap mode) can be had from the CVS repository at SourceForge, though I can't vouch for them with my limited CVS knowledge.

My 3.89 doesn't mention --nogap either, but neither does it complain when I put it on the command line. I haven't checked its functionality yet, though.

I tried out a 3.89 build last night. I used CoolEdit to split up a wave file of Tom Sawyer into three parts. I checked the three WAV files with WinAmp's gapless output plugin and they sounded correct. Then I ran LAME on the three files: "lame --nogap 01.wav 02.wav 03.wav" and it seemed to like those command-line parameters and it seemed to encode them properly. But when I played back the three files in WinAmp with the gapless output plugin, there was still a blip between each file.

So either the feature is not yet ready for prime time, or LAME isn't the answer.

I'm using Lame 3.89 with the RazorLame shell. I suppose this will also work with this shell. Otherwise it seems like a whole lotta work to me, I mean if I had to enter each file manually.

(I think I'll try it anyway Tony )

Hmmm... I did it between the first two tracks of DSotM and it seemed to be fine. I used ``lame -b 128 -h --nogap 01.wav 02.wav''. This was a binary of LAME I compiled my self for my Sparc Solaris machine, though. I can't imagine that that would make any difference, but maybe there's something different with a distributed binary.

It's also possible that different kinds of material produces different results. Maybe my hacked worst-case-scenario test was too hard for it.

Try doing the whole album and see if all transitions work?

Try 3.90 alpha 8. There were changes made in the last few weeks.

Darn, my version was from July 5.

So hard to tell where to get recent versions? Where can I get a binary of that one?

Look under the alpha version list, and you will see one from 10/31.

http://home.pi.be/~mk442837/

Darn, the link there to the 10/31 file is broken.

Oddly, when I encode all 9 tracks with the --nogap option, the hiccup becomes more pronounced. Still have to listen hard for it, though. I'll try the latest CVS version and see if there's any difference.

Okay, I tried the latest alpha (Terminator sent me the file directly), and they're certainly doing well. They are ALMOST there.

The WinAmp plugin plays back my worst-case-scenario "Tom Sawyer Cut Up" almost flawlessly. Empeg 2.0b3 is a little worse than the WinAmp plug in, not sure why.

I get the following error when trying to use --nogap with a recent LAME 3.90 Alpha 8 build (October 29 build):

lame --nogap 1.wav 2.wav

Input file and Output file are the same. Abort.


Am I entering the command incorrectly?

Hmm. I used almost exactly the same command, but with a couple of differences:

1) The files were 01.wav, 02.wav, 03.wav, and 04.wav

2) There were four files instead of two.

3) I specified lame.exe specifically instead of just "lame".

Perhaps it needs the two-digit file names to correctly determine sequence? And perhaps it needs at least three files so that it knows it's in multi-file mode? Or maybe you were invoking a lame.bat file instead of the EXE directly?

I've tried similar scenario yesterday, with three parts of the last few minutes of Tchaikovsky's 1812 ouverture (the noisy part wwith real cannon shots, church bells etc). I used EAC to rip specifying exact start/stop frames (perhaps cutting a single wav file is a better idea). I listened only on empeg: independetly lame-encoded VBR files produce quite pronounced transitions. Original wavs and --nogap encoded CBRs are noticably better, but still not there by far. I expected better results, at least with uncompressed files (I will have to check them with WinAmp nogap plugin to rule out ripping error, though). That said, one is unlikely to notice transitions in a normal in-car listening environment without actually looking for them.

Latest Lame alphas's can be found here

In reply to:

---

Latest Lame alphas can be found here

---

Unless your corporate Web proxy think's that's "pornography"