I kow there is a gap killer application for download but I also rememeber seeing (which i cannot now find) a way to rip cds continuously with que sheets. I cannot seem to find that now. Does this exist or not and if so, would the que sheets be supported by the empeg?

Yeah there is a good cue sheet gap killer, but its not supported by the empeg. I think you can find it at http://www.guerillasoft.com .

Has anyone tried using the Seek Tool with a large single-track-ripped album?

Never mind. I just realized that this would only be useful on continuous-track material. And there wouldn't be any silent spots between the songs for the seek tool to find.

My problem is many three CD sets of continuous many (25+) tracked material. According to the FAQ, there is no easy answer. I don't even have time to rip my CD collection much less make them gapless. By the way, I don't think people realize how extensive the FAQ is.

I don't even have time to rip my CD collection much less make them gapless.

With the 2.0 software, the car player does a decent job of playing the MP3s gapless even if the tracks aren't "tricked out". The blip between two tracks is very tiny.

If the blip still bugs you, and you want to make the MP3s gapless, then you have to do a little work because of this limitation of the MP3 format. This isn't the car player's fault, it does everything it can with what it's given.

By the way, I don't think people realize how extensive the FAQ is.

Thanks.

I have a question for everyone: Do WMA files have bits of silence at the beginning and the end like MP3s? Or can WMA files play gapless?

they can play gapless. at least through WMP i dunno about the empeg.

I don't know if this is really relevant, but I made a program called MP3 TrackMaker that splits up MP3s (and joins them). Anyways, I just recently released a new version that supports cue sheets. I find most of my sheets from http://www.regeert.nl/cuesheet/ which is powered by http://www.freedb.org. This way, if you have a huge single file rip, you can split up by simply importing the cue sheet into MP3 TrackMaker. Since it splits on frame boundaries, it should make the resulting MP3 files gapless (it doesn't insert silent frames or anything). Anyways, if you're interested, I'll post a link for my program. Unfortunately I do sell it (yes, I know ), but it's pretty cheap.

As I discuss in the FAQ entry, even when you split MP3s on frame boundaries, they do not play back perfectly gapless, because of the bit reservior. THIS HAS BEEN HASHED THROUGH BEFORE.

My gapkiller program will also split files on frame boundaries, so I know this from experience.

I'm sorry, I forget some things. No need to get angry. We've got empegs, be happy

Sorry.

Actually, when you split on frame boundaries and play back on the car player, the between-track blip is barely noticeable. So that's a very good solution.

I will experiment with WMA. If it turns out that WMA files really do play back gapless, I will add that information to the FAQ.

No problem ... Anyways, where did you find that information about that limitation being present even when splitting on frame boundaries? Or did you just figure it out on your own when experimenting? It's too bad that it doesn't work, it seems like it should. I wasn't aware that data from previous frames has an impact on the following frames... I thought that was only in VBR files.

I don't remember where I first learned about the bit reservior. I've seen it documented in a bunch of different places. And to my knowledge, the bit reservior is present on both CBR and VBR files.

I believe (not sure about this) that the nogap option in LAME requires that the bit reservior be disabled at the encoder level. I could be wrong about this. If that's the case, then the nogap option might cause the files to be less "efficient" in terms of trading quality for size, so you would need a bigger file to achieve the same quality. That is, if I understand how the bit reservior works.

By the way, an update on WMA gapless: Did not work when I tried it just now. I had a set of perfectly gapless WAV files that I double-checked to make sure they were gapless. Then I encoded them at 160kbps WMA and put them on the player. There was a distinct pause between each file.

I do not know if this pause was encoded into the files or if it was inserted by the player software. But the pause happened on both Windows Media Player as well as on the car player (less badly on the car player).

If it was caused by my encoder, then I would like to know. Those of you who say that WMA is gapless: What encoder was used to encode these allegedly-gapless files?

I assume incorporating que sheets into the player software would be a daunting proposition and I assume nonstandard (meaning no standards on que sheets). Version 2 does a good job but sometimes more noticable than others and a function of the content at the end and beginning of the tracks in question (namely volume). I assume the remnants are the above limitation of mp3s that has been discussed.

I'll try the GapKiller both ways.

That would be neat though if you could use a cue sheet single MP3, and the empeg player software would read the cue sheet and treat the single MP3 as tracks.

It's not even totally a bit reservoir issue. The fact that mp3s are encoded in frames that have a constant real-time length (that is, the fact that each frame must be 25.7 ms, or some such number) means that if your track isn't an exact multiple of that length, then it has to insert blank space. (BTW, the frame length varies depending on bitrate, sample frequency, etc. And that exact number I gave is totally made up.)

Also, in my experience, tossing the bit reservoir does something more along the lines of making the volume ramp up, rather than creating silence. Not that that's not equally as annoying.

The "padding out to full frames with silence" issue is a valid issue, but it is not related to our current discussion of the bit reservior.

If you have encoded an entire CD as one huge MP3 file with no track splits, then split that file on frame boundaries, then the padding issue is worked-around. However, the bit reservior issue is not worked around.

C'mon people, get up to speed on this stuff, K?

I know, I was just filling in the gaps, as it were, just to make sure someone who didn't know that point didn't decide that doing it a way where that became a problem would solve the overall problem.

You can get up to speed at the link below.

http://lame.sourceforge.net/tech-FAQ.txt

What about having the player software sort of dynamically merge the last MP3 frame from the previous song to that of the next song? Kinda just like treating the individual MP3s in a playlist as a whole?

This would cause errors on files that weren't meant to go together like that.

In reply to:

---

I believe (not sure about this) that the nogap option in LAME requires that the bit reservior be disabled at the encoder level. I could be wrong about this. If that's the case, then the nogap option might cause the files to be less "efficient" in terms of trading quality for size, so you would need a bigger file to achieve the same quality. That is, if I understand how the bit reservior works.

---

IINM, --nogap does not disable the bit reservoir - instead, it causes it to be emptied at the end of each track. So there's no degradation of quality.

It is possible to disable the bit reservoir (--nores, IIRC) - this is what you must use if you're making one big MP3 and then splitting it later. This does potentially reduce the quality (unless the track were so even that the reservoir was never called upon anyway).

I need to investigate the begin/end markers that Lame puts into MP3s and see if they can give us seamless playback. If so, I'll make a concrete suggestion into Wishlist forum. If anyone beats me to it, I won't be upset...