Hey

Live acts or mixed music is usually ripped as one big file along with the cue file. This has the advantage of providing gapless play on any mp3 player even though the mp3 format does not do gapless play as well as other formats. Of course the cue file may not be read by lots of players that cant parse a cue file, however in the interests of gapless play this is livable to a certain extent.

I was wondering whether it was possible to create some software that can read the cue file and BIG mp3 file and create smaller files ( like APL used in APE). These smaller files act as offsets to various track start positions. So a playlist could be constructed that included these small files and the mp3 decoder would access the same file ( thinking it was playing separate files) along with track name display. Sounds good in theory but this requires the decoder to be aware of these little files, which is not the case currently so this scheme wont work.

So what i am thinking of is similar to the APL idea EXCEPT the files will have mp3 (or whatever extn a mp3 decoder understands) extensions. Now the content of these files must be able to somehow trick the mp3 decoder into thinking its seeing a real mp3 file and contain a track name as well as offset information so the decoder know at what point to play the track. The decoder thinks its playing separate tracks, but in reality it is just accessing the same BIG file.

Hope i explained that ok

IF the above idea was technically feasible, it would allow gapless play along with track info display on whatever mp3 player out there taking care of the gapless+track name display issue.

What do ppl think....is such an idea even possible with mp3s ? I am not an MP3 format expert so i will defer to the experts on this forum.

Hello,

I am just adding some thoughts or rather the technical difficulties.

Any decoder will accept one frame of data and decode to give one frame.(provided the main data buffer with its main data pointer is taken care off:-)

1.In case of a large single file, is the layer (1, 2 or 3) and sampling rate and of all individual files are same? If not there can be two problems. Standard says that the deocoder needs a reset if it encounters a different sample rate. Problem is since the synachronisation with 0xffe is not always guaranteed and the decoder, from the second frame onwards tries to synchronise with all extra parameters are known to him (Sampling rate and layer). So in case of second file with different layer or sampling frequency, the decoder will fail to find the synchronisation word.

2. Track info will be there in the id3tags and there again id3 has different versions and I believe one is at the beginning of the file and another is at the end of the file ( I am not pretty sure if I am wrong some one please correct)

3. To show the progress of decoding ( what I mean is the duration of the file and how much it had advanced in any players) it will be difficult.

4.The overlap buffers of IMDCT as well as the synthesis filters need a reset ( I am not sure how much is the effect) and also the main data buffer and the main data pointer?

But inspite of all these, if your cue file can address all these issues, I feel it should be possible, but not with an existing decoder but with a custom made one.

musiCutter

Thanks for the reply. This is just proof of concept at this stage, so criticisms, comments are welcome.

Adressing your points

(1) for the sake of simplification, we stick to CBR.

(2) can consider tags V1 for the moment, This will ensure uniformity. In any case tags will be either V1 or V2. The pseudo mp3s should contain enough information to allow any ID3 taggger to tag in either mode.

(3) Let us say we have one big mp3 called A.

A's cue file will be passed through a pseudo mp3 generator program that will create separate tracks ( A1.mp3, A2.mp3, ...An.mp3) referencing A. From the cue file the (calculated) duration of the tracks+tag nfo will be placed in the pseudo mp3s. These pseudo mp3s will not be split version of A, and only contain enough information to allow any mp3 decoder to think they are separate mp3s.

We create a playlist of files ( A1.mp3, A2.mp3, ...An.mp3) and call it A.m3u

When the mp3 player is passed A.m3u, the decoder reads A1, it will understand the tag and think its looking at a real mp3. At this stage some magic has to occur to point decoder to physical/logical position of track A and play track A from the beginnning. When it reaches the end of A1, control shifts to the mp3 player and it reads the next track A2.

A2 ( as A3...An) will contain offset information taken from the cue file. Again it will reference A and start playing at the time its supposed to begin. This requires the ability to tell the decoder to start play at an offset postion of A. I am not sure if mp3 decoder can understand to play at offset positions instead of always the beginning of an mp3, maybe some one can clarify this.


I am interested to make this work with existing decoders. Creating yet another decoder defeats the purpose of the exercise i feel.

The aim is

(a) its desirable to be able to access tracks from within a bigger file so they can be inventoried in any media program that has database. Also allows random access to any of the tracks within the mix. No need to create a split version of A just for this ( waste of disk space)

(b) if one wants to listen to the big file in sequence, there is benefit of having tagging information available along with gapless play on any mp3 player out there without needing cue file support from the player.

I understand there are better auido formats that can handle gapless play and are lossless. But this idea/hack is for ppl that already have mp3s and dont want to transcode or save to a lossless format (APE which quadrupes the file size).

Did you check the link from my previous post?

yes i am aware of musi-cutter.

But if i want a gapless version of a mix, music-cutter even though it cuts at frame boundaries will have gaps when playing. i have noticed this with a few albums.

What about mobile MP3 players which are not very gapless play friendly and big mp3 file is best, but then no track info is available.

Maybe other can comment on this.

How gapless do the split mp3 tracks compared with the original Big mp3 ?

Also...using musi-cutter i need to backup the original big Mp3, i am hoping not to do that.

Of course depending on the feasibilty my above idea, i may have no choice but to go with musi-cutter. Lets see how the concept plays out.

musiCutter can join files too. Comparing the original and the "cutted-joined" one will show they are bit identical (no need for backup, just keep the CUE sheet). I think that's the most you can do.

I tested musicutter for bit loss.

To my surprise its as u say, bit identical. I pushed this up to the 5th generation split/join and it still was identical with the original. I even tried with ABR files and no loss here. So i suppose the split files can be kept and when reqd joined up for gapless play on portable players.

i find winamp (2.91) with a look ahead buffer of 500ms handles the split files quite well and the gaps are not noticeable.

I did at times encounter an error with musicutter when splitting certain files (CBR)

Frame header not found in source:(some position) x bytes skipped where x < 100

i thought this might be related to the tags so i removed them but the same error came up. I set musicutter to cut nearest to the frame, i tried the other 2 settings (before & after frame, wonder why these extra settings are provided ?) but no difference. Mp3 utility does not indicate anything worng with the mp3 either so no bad frames or sync errors.

I did a bit compare after split then join and the results were identical. I am not sure whether i should be bothered by musicutters error message.

EDIT

Ran the split files through Encspot 2.0,
- the first track displays the wrong kbs but the smae encoder as the parent it came from ie LAME 3.93
- the last track displays the right encoder.
- All tracks in between display as coming from Gogo encoder.

THe split tracks seems to be confusing encspot.

OK..musicutter can split & join files flawlessly.

Now ..is there a player out there that can play the split files flawlessly ?

The test for this is simple. diskwriter.

if a wav compare of the original and the split files played in sequence is identical.

i tried various gap killing plugins but could not succeed with the above.



i think the problem here is, its too late to pass any filelocation into the decoder. Or the decoder does not deal with file location at all, its the players job to do that.

So the player needs to be passed a pointer to the right position of the big mp3 which it can pass on to the decoder. m3u & pls are lists of pointers to files....

hmmmm...

a plugin could !! but then this does not work on all payers

2 programs needed.
- a pseudo-mp3 generator
- plugin that can understand the pseudo mp3s. plugin reads the pseudo mp3s and then references the big mp3 at the right offset.

This will allow certain tracks to be isolated from the big mp3 and say combined in a playlist with other mp3s which mp3cue plugin does not allow.

Hi,

Some time ago I saw a cue file describing an album - but not with a single image but with separate mp3 files for every track. If these single mp3 files where decoded to multiple wav files this cue file could be burned as one image to an audio cd.

What I was wondering: is it possible to create such a cue file for an album and the exact lengths of every track are used to generate the cue file? So when I decode the mp3s and burn a CD via the cue file, I get a CD without gaps even so the mp3s might contain padding silence at the end of a frame; thru the exact lengths from the cue file are used and possible paddings discarded?

Is this even possible - and if so what software could do this?

thank you very much

Best thread resurrection, ever!

If you used LAME to encode the MP3s a cuesheet (or similar) is unnecessary; you could burn without gaps anyway. I'm not sure if all apps could, but I expect foobar would.

As to your idea: I'm pretty sure that nothing can do this. Cuesheets are not accurate enough to cut an MP3 at frame level anyway.