Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Cue sheets (Read 23490 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Cue sheets

Reply #25
Quote
MP3brfix (bit-reservoir-fix) v0.94(beta) © 2003/02-03 by ZeBee

first frame:
  MPEG1 Layer3 64kbps 44100Hz J-Stereo
  Xing-Tag present
  flags: [fc] [bc] [toc]
mp3 frames: 17682, VBR (213.6 kbps)
Bit-Res errors: 0
no CRC protected frames found.
ready.


I guess I know what happened. Try the new mp3brfix version.

edit: some more explanations: Appearently the splitter wrote a frame containint a Xing tag. The thing is that if you decode this frame es well you have enough bits in the reservoir. That's why the old version of mp3brfix did not complain. The newer version ignores all the main data bits in such a frame.

get it here

Sebi

Cue sheets

Reply #26
Sebi:  THANK YOU!!!

The new version works great, now I can use normal cue splitters without having to use foobar to split and re-encode!  And using mpg123 provides gapless playback!

Thank you again, great work. 

Now jud, could you add that option into splitcue?

edit: small complaint, it does leave a very small (but still noticable when playing music that is mixed together) gap between the tracks that isnt removed by mpg123 or silencing tools in playback.

Cue sheets

Reply #27
Quote
The new version works great, now I can use normal cue splitters without having to use foobar to split and re-encode!  And using mpg123 provides gapless playback!

edit: small complaint, it does leave a very small (but still noticable when playing music that is mixed together) gap between the tracks that isnt removed by mpg123 or silencing tools in playback.
[a href="index.php?act=findpost&pid=307836"][{POST_SNAPBACK}][/a]


That's due to the silencing of undecodable frames. I said it's a destructive algorithm.
The next step would be to place the missing bitreservoir data right behind the frame containing the LAME tag (instead of silencing frames) and adjusting the LAME tag to compensate for the higher delay withing an mp3 splitter. (I won't do it.)

bye,
Sebi

Cue sheets

Reply #28
Quote
The next step would be to place the missing bitreservoir data right behind the frame containing the LAME tag (instead of silencing frames) and adjusting the LAME tag to compensate for the higher delay withing an mp3 splitter. (I won't do it.)


So that would fix it?  I wish I knew more so I could do this myself!

 

Cue sheets

Reply #29
Quote
I tried your method with using the last frame from the previous track and zero'ing the side information (32 bytes after the 4 byte header, assumg M1L3).  This produced a small but noticeable gap between tracks, and since I can't hear the difference when it just does a clean frame break I went with that method.

If you have any other suggestions I'd be willing to try them out if you're too busy.
[a href="index.php?act=findpost&pid=307710"][{POST_SNAPBACK}][/a]

Since you are rewriting the LAME-tag-frame (are you?) you could increase the encoder/decoder delay value by 1152 if this is possible. That should remove the gap if you play it on LAME-tag-aware decoders.

Sebi

Cue sheets

Reply #30
Quote
Since you are rewriting the LAME-tag-frame (are you?) you could increase the encoder/decoder delay value by 1152 if this is possible. That should remove the gap if you play it on LAME-tag-aware decoders.

Sebi
[a href="index.php?act=findpost&pid=307863"][{POST_SNAPBACK}][/a]


Yes, I'm rewriting it to be kind to my friend foobar.

Excellent idea about encoder/decoder delay.  I'll try this later tonight.  Thanks Sebi!

digi, I tested with foobar, Winamp, and Media Player.  I'm not sure which decoder libraries they're using but I haven't changed the defaults.

Cue sheets

Reply #31
BTW: It may be necessary to duplicate more than one frame. Imagine a 128 kbps CBR stream where the framesize is around 8*417 bits and the main data section is around 8*(417-4-32) bits large and the bitreservoir is 8*511. So, if the bit res pointer in the 'critical' frame exeeds something around 417-4-32=381 you need the next to last frame of the prevois file as well.

This is how I did it:
- remember the count of valid bits in the bitreservoir in some variable 'bitResSize' (in bytes)
- read next frame, bitResPointer = first 9 bits of the side info block (it's 8 bits in case of MPEG2/2.5)
- if the bitResPointer is greater than bitResSize -> undecodable frame -> silencing
- compute amount of maindata bytes in the current frame (framesize in bytes - hs - sis - crcs)
- set bitResSize = max(bitResSize + maindatasize, maxBitRes)

hs = header size (4 bytes)
sis = size of side info block (32,17 or 9 bytes depending on the type of stream)
crcs = protectionbit == 1 ? 0 : 2 bytes
maxBitRes = mpeg1 ? 511 : 255 bytes

So, the splitter should calculate and memorize last seen frames and how many maindata bystes are present in the last seen frames. At a splitpoint the new frame's bitResPointer is to be examined. Depending on that value and the size of the preveois maindata sections a count of frames can be calculated that have to be duplicated (with zero'd side info blocks). Due to the duplication/silencing of frames there'll be a gap of (mpeg1 ? 1152 : 576)*(count of duplicated frames) samples. -- Could be compensated via LAME-tag, I guess.

bye,
Sebi

Cue sheets

Reply #32
Sebi, Thanks again.  I finally found a track that blips in Winamp.  foobar is too damn smart to test with.    I imagine Winamp does not adjust for the sample offset since setting the encoder/decoder delay, even to a ridiculous number, has no effect and a small gap is present.  Do you know of a setting to make use of the delay in the LAME tag?


Cue sheets

Reply #34
Jud,
It's getting better!
So far, I have only found one file that made a small sound at the start when split with the new version and the bit reservoir option enabled.  Mostly though, the transitions between tracks aren't perfect; it will skip a bit or something (like it does when fixed with sebi's mp3brfix tool), but there were two tracks that blended perfectly, which was nice to hear!
In winamp i'm using the mpg123 decoder so it will remove the silent frames at the beginning and end of LAME encoded tracks on playback.  And I need to have the bit reservoir errors fixed otherwise I can hear the sounds on my ipod, on which (unfortunately) I can't change the decoder on.

Please keep on trying to sort this though, because you have done a lot already, and it's making me happy .  This splitter already beats all the others that I've tried.

If you want me to record it making any noises or the skips between some tracks when there shouldn't be, or anything, just say.

Thanks.

Cue sheets

Reply #35
I already tried that method. Well, at least, actually checking the packet/byte dependency and supporting only single-packet dependency. Even blanking the side information, or simply blanking the main data length fields in each of the granules, results in slightly different output.

Even when using the LAME tag delay/padding information to absorb the difference (accounting for decoder delay at the start, and including it in the padding) the resulting audio data is slightly different from the original range. Sometimes the ends line up, and sometimes there's an audible difference. There's probably a lot more to this than simply silencing the reservoir fill packet...


Regarding the LAME gapless information, as noticed above. The VBR packet should always be skipped, but it is up to the splitter to include any silence packets in the delay/padding. Decoder delay should also be included in the padding.

So:

MPEG-1 layer 3, VBR header with LAME tag info, 16 packets of audio.

16 * 1152 -> 18432 samples.

Header specifies a delay of 576 (usual with LAME encodes.) and 804 worth of padding, for a resulting length of 17052 samples.

In CoolEdit Pro, Adobe Audition, or any other editor which does not account for VBR packets or delay/padding, you would make the following cuts:
  • 1152 samples from the start for the VBR packet.
  • 576 samples from the start for encoder delay.
  • 529 samples from the start for decoder delay. (or 481 for layer 2. Both assuming reference decoder or similar.)
  • 275 from the end for padding minus decoder delay.

I'm not sure how most decoders handle silence frames (32kbps or otherwise) when no VBR header is present. As far as I know, they should be decoded and output normally if VBR header is present, and only the resulting samples skipped to account for specified encoder delay/padding.

(Did someone already post about encoder delay/padding handling in another topic?)

Cue sheets

Reply #36
Any further progress on this?  I've got quite a few mp3's waiting to be split, and I'd like to do it properly!  I found an app called mp3directcut that cuts the mp3's with no gaps or noises, but gets loads of resyncs, meaning that sometimes the start of each track is a long way from where it should be.
I noticed a fix mp3 header option when you right click on an mp3 in foobar.  This fixes the noises, but, like sebi's tool, leaves gaps between the tracks on playback.  The only solution so far that doesn't is splitting in foobar (re-encoding).

Cue sheets

Reply #37
Hey,
Just tried something different, and it works almost perfectly.
If I fix the mp3's with sebi's tool, and then fix the mp3 header in foobar, disable padding (set padding as 0), and check rebuild entire stream, when i play it in winamp I don't think there is any gap, but it kind of jumps slightly.  Maybe that is a gap.
Anyway that works quite well, but I would prefer it to work perfectly.

Cue sheets

Reply #38
Found a very good if not perfect solution:
Split using CD tag with the bit reservoir option enabled, then fix with sebi's tool.  Haven't been able to fault it (at least I don't think I can hear any problems )

EDIT: For some reason i needed to use sebi's tool the first time i did a split, but just using cd tag works great now.  Nice wok Jud!

Cue sheets

Reply #39
I've good and bad news:

Good news: I had some free time yesterday and started developing an app which is supposed to do sample granular splitting perfectly. It's almost finished.

Bad news:
see this thread

Sebi

Cue sheets

Reply #40
I finished writing it. People interested in it should whine in the thread I linked above to make it worth trying out.

Sebi

Cue sheets

Reply #41
Whine??

Cue sheets

Reply #42
Quote
Whine??
[a href="index.php?act=findpost&pid=313463"][{POST_SNAPBACK}][/a]


You may substitute it for "complain" in this case.
(Complaining about Foobar 0.8.x not acceptiong encoder delay values above 1152 which renders my splitter useless)

Unfortunately I can't try Foobar 0.9 beta.
(I'm still using a Win98se box)

Sebi

Cue sheets

Reply #43
Is this a plugin for foobar then, to split the tracks?  I don't think Jud's tool does work perfectly yet.  Will foobar 0.9 be released soon (i.e. can't you wait for it) or will you not be able to use the final 0.9 on 98?

Cue sheets

Reply #44
No, it's not a plugin. it's a standalone mp3 splitter.
AFAIK Foobar 0.9 (beta) doesn't/won't run on Win98.

Sebi

Cue sheets

Reply #45
Good stuff sebi.  Why do you need foobar?  I added a little support to your thread about the limitations.  Can't you do what kode54 said though?

Thanks for this app sebi, if it gets released

Cue sheets

Reply #46
Oh, boy! I'm currently testing it on a WinXP box with Foobar 0.9 beta 5. It works like charm. I've splitted an mp3/cue image (DJ set). Each resulting track's length is divisible by 588 (yeah! sample accurate splitting, baby!). There are no gaps/clicks between the tracks to hear. mp3brfix reports "no bitreservoir errors"

I'll be releasing it after some more testing.

Quote
Why do you need foobar?


The number of players which properly handle the LAME tag and don't close and reopen the audio device (between tracks) is very limited. (I'm only aware of Foobar 0.9 beta doing all this). But I guess WinAMP + in_mpg123 + some good output plugin will do it as well (havn't tried). To answer your question: A decoder which properly handles the LAME tag is needed in order to be able to test the splitter.

I'd be happy to see a patch for Foobar2k 0.8.3 released.

edit: see this thread. Post #5 is about a Foobar 0.8.3 hack to make it work.

Sebi

Cue sheets

Reply #47
Quote
I'd be happy to see a patch for Foobar2k 0.8.3 released.
[a href="index.php?act=findpost&pid=313933"][{POST_SNAPBACK}][/a]

You better not hold your breath...

Cue sheets

Reply #48
Nice one sebi!  So will I have to play the splitted tracks in foobar?  Or is that just for testing?  I'm guessing this app will support cue sheet splitting then?  Is it a command line app?

Thanks again