What is the deal with ID3 tags affecting gaps between songs? Has anyone noticed a difference in the gaps between songs between ID3v1 tags, ID3v2 tags, or no tags at all?

A properly written decoder should not be affected by any kind of tag.

The skinny on gapless playback can be found here

Thanks Tony. A few more questions. One, can you do searching by ID3v2 tags for year and such, or are only ID3v1 tags supported. Also, I use a distinct filenaming type but I don't have any ID3 tags on my files. Are there any apps out there in which you can parse the file name and apply an ID3 tag based upon it?

The player doesn't use the tags in the music directly for searching. It uses the database built by emplode. Emplode builds the database from ID3V2, ID3V1, Filenames or information you type in yourself. It only uses the filename if there are no tags.

Since you have filenames and you've got a specific format, you can use MP3 Tag Studio to parse the names and populate ID3 tags. I suggest doing only V2 and no V1 at all. You can get it from www.magnusbrading.com/mp3ts/

Also, when making edits with emplode, it will only affect the information in the player database. Changes will not be made to the MP3 files or their tags. At least not until some future release of the software with that feature. :)

Emplode offers some really useful view modes that allow batch operations. MP3 Tag Studio only works to accumulate batch lists by directory structure. It's good at what it does and should work fine to fix all your files.

Bruno

Hybrid8 is correct. I wanted to clarify a couple of things, though:

1) When you first send your songs to the player, it reads the tags to get the information for its song database. It will read either V1 or V2 tags, or both.

2) It's important to have your tags filled out ahead of time so that the search features on the player can be useful. You can search by year, by genre, by artist, by title, or by album.

3) You said that you have a strict file-naming system. This is nice, but the player software won't use it-- the file names don't survive the trip to the empeg. MP3 Tag Studio will do a great job of converting those file names into tags, so it should be a snap to have it do all the work for you. Make sure to get that job done while you wait for the player to arrive at your doorstep.

4) Tags are better than file names because they can contain characters that aren't allowed in file names. For instance, if you have a song title with a question mark, or a slash character, or an asterisk, or some other illegal-for-DOS character, then you can put it in the tag.

More details on creating MP3s and tagging them can be found in the FAQ.

I've been cleaning up ID3 tags w/ Music Libruary. It lacks Tag Studio's trim functions, but allows CDDB lookup based on existing ID3 (v1 or v2) tagged files. It's a little complex to use at first, but saves loads of time with re-tagging.
http://www.wensoftware.com/MusicLibrary/

Keil

Yes, full of features but not very intuitive and quite easy to mess the things up with if trying to use it immediately without R'ing TFM first I downloaded it, played a little, and on the second attempt to run it the program started claiming that an OCX that it placed in system dir itself is out of date... Removed it untill I gather enough patience for fighting M$W again.

does anyone know the best technical resource on the net available on the subject of why gaps have been so difficult to get rid of? i am a dj and listen almost exclusively to mixed music.... this is incredibly annoying. don't understand why a home cd player (or a computer cd player) can play the songs seamlessly, but when they are ripped and encoded, there seems to be an issue. also, if i burn a cd (w/ regular wav files) *from* my encoded mp3s, the gaps go away....

so peculiar.

d.

There have been several long threads on this, including a recent one on experience with with new --nogap lame option (not stellar, in short). Rather than trying a recap, I will simply advise that you search a bit around the board . I believe some of those posts contained links to relevant net resources, too.

If you come up with a novel idea, please make sure to share it!

Since this is actually not too complicated, I'll explain real quickly. CD tracks (and WAVs) are just streams of data. When they hit the end of audio, they stop. mp3's, on the other hand, are formed in blocks, where each block comprises a set number of samples. If the audio ends before the end of the block, then the block must be padded out with silence.

Hi, I'm a fairly new empeg owner. I have used gapless / seamless playback of mixed cd's with a winamp plugin called MP3CUE @ http://www.guerillasoft.com. When u play a large mp3 and it has a cue file within the same directory, it interprets the cue and provides track information. EAC can generate the cue file upon ripping into a large mp3. I hope someday the empeg guys can implement this, by reading the cue file with emplode or whatever, then embedding the track info for the mp3 into the music database and when the track is played we'll have seamless playback for good... I have hundreds of albums based on cuesheets.

I'd been thinking about the same thing (too lazy to post about it), but using the ID3v2 ETCO $FD tag instead of CUE sheets. Same difference, though, I suppose.

does anyone know the best technical resource on the net available on the subject of why gaps have been so difficult to get rid of?

No, but we can explain here. This is also paraphrased in the empeg FAQ as well as in the Readme file for my Gapkiller program:

1) MP3 files were never meant to be played back-to-back seamlessly. When they designed the MP3 specification, they simply didn't think of this.

2) Each frame of an MP3 is a fixed timespan. You can't have "half of a frame". So, no matter what, all MP3 files always have their last frame padded with a certain amount of silence.

3) MP3 encoders have some sort of a strange thing where the very first frame almost always has some silent padding at the beginning. Note that this is unrelated to #2, above. I don't understand the technical details of this one. Maybe it's got something to do with the encoder needing to "spool up" and fill the bit-buffer or something. I don't know exactly. I actually e-mailed Fraunhofer about this one and they basically said, "yeah, it does that. It's normal. There's nothing we can do about it."

4) MP3 frames are interdependent. They use a "bit reservoir" which allows a later frame to use some of the data from a prior frame. So frames within a file can play seamlessly against one another, but frames from two separately-encoded files cannot.

5) Playback programs almost always insert additional silence of their own. They do not properly spool the data so that the two files can play without a hiccup between them. The 2.0b7 car player software is very good about this and does not hiccup between two files. However, the MP3s themselves still have the encoded silence (above), so there is often still a hiccup.

Have you read the FAQ entry and/or tried my Gapkiller program? I can get Dark Side of the Moon playing perfectly on my car player now, except for one particular song transition where there is a very slight hiccup.

I think this idea was also mentioned on the board (when we discussed how cutting MP3s was not trivial - partial blocks, bit reservoirs etc), but I don't remember whether we got any feedback from empeg guys.

If ogg support is implemented in the future, then you can have gapless playback.
:-)

How long in seconds(or ms) is each frame?

If it is VERY small in length then why not have the last frame of applicable songs just removed?

How long in seconds(or ms) is each frame?

For most MP3s made from a CD (44khz 16-bit stereo), the length of a frame is approximately .02612/second long.

If it is VERY small in length then why not have the last frame of applicable songs just removed?

Yes, that's the very concept under which my GapKiller program operates. Only it's not enough just to trim the last frame. You have to mess with trimming different numbers of frames before and after each gap, and some trial-and-error is required. Have you tried it?

Frame sizes vary depending on bitrate and sample rate. But a 128kbps 44.1kHz frame is, if I did my math correctly, about 0.026s. Some people can hear that little amount missing (I can, for example), and other people can't. But there is often a gap at the beginning as well, which I don't fully understand either, and that is (almost?) impossible to remove. But if you want to give it a shot, Tony has a utility called GapKiller on his web site

Yah but how does OGG handle tags? Tags cause skips usually unless the encoder is smart enough to skip over them.

Tags cause skips usually unless the encoder is smart enough to skip over them.

Arg, how many times do we have to repeat this: Only badly-written software would cause a skip because of a tag. You have it backwards. It's not "if the software is smart enough", it's, "if the software isn't completely and utterly stupid".

Yeah. Well Ogg is a new format and I doubt every encoder/decoder out there is going to Do The Right Thing. Look how long it's taken for even a healthy majority of the MP3 en/decoders to get things right, and we still see examples on our Empegs where things aren't as they should be in terms of tags and the like.

I was just pointing out that Ogg is not the solution to this problem, smart software is.

I have no idea. But the decoder (I assume you meant that) should automaticly skip over the tags unless its a piece of crap.

Sean

Yeah I meant decoder. I hadn't had my morning cup of coffee before that post. Bad, bad move.

The encoder leaves silence at the beginning and at the end of the song. Chopping off frames that are involved with the bit resovoir can cause annoying noises, and taking too many frames off will truncate the song. It takes too much time to sit there and play with every song - I've only messed with it on a cd I really wanted to play gaplessly.

Yeah, I figured you meant Decoder, I wasn't going to pick nits.

You do make a good point, though, that smart software could solve the problem. I can envision that someone might be able to write an MP3 player which would decode two MP3 files and look closely at the audio data at the end of the first one and the beginning of the second one. Even if the files were encoded with silent gaps between them (silence embedded in the first and last frames), the -DECODED- raw wave data would show it pretty clearly and the playback program could simply skip over that tiny bit of raw silence and play the resulting audio back to back. No "de-gapping encoders" necessary.

So why doesn't such a piece of player software exist? I haven't seen it.

The format is the problem, not the software that plays it. Ive emailed Franhauffer and heard from the person in charge of maintaining the lame source code. They both tell me the same thing. Theres nothing that can be done. I have the specifics somewhere, but I've posted them before. Some efforts were made to work on a nogap switch in lame, but its a pain to use and doesn't work very well anyway. There was talk (rumors) a few months ago about the main developers shutting down the lame project and moving on to a new format - most likely ogg. I'm not on the mp3 encoder mailing list anymore, so I don't know what theyre up to, but new versions are still coming out so they must be doing some work.

Sean

"So why doesn't such a piece of player software exist? I haven't seen it."

The closest I have seen is the mp3cue thing written by the same guy that did encspot. But its a plug in for winamp. And it doesnt do that. It just has a cue sheet for one giant file.

I actually use a program I made called MP3 TrackMaker http://www.heathcosoft.com/products/mp3trackmaker. It works good with trance mixes and the like if they are one big file. It will split them on frame headers by the time list you give it, which works good (I don't hear gaps if there aren't any tags).

In reply to:

---

I actually use a program I made called MP3 TrackMaker ... It will split them on frame headers by the time list you give it, ...

---

How does it deal with the bit reservoir? Or do you have to encode your files with lame --nores or equivalent, like if you use mp3asm?

How does it deal with the bit reservoir?

I'm guessing that it does not deal with the bit reservior at all. It simply splits the file.

Having done this myself (my Gapkiller program also allows you to split files on frame boundaries), the resulting files will still play even if the bit reservior is split across files. There will be a slight glitch at the boundary because of this, but it will be a less annoying glitch than an actual gap of silence.