Gapless MP3's + Streams (1.19)

@centaurz

TuneNet's gapless mode is exactly as it describes. It makes sure that the first sample of the current tune comes directly after the last sample of the previous tune, so there is no gap.

This is fine with formats like AIFF, but with MP3 this is a different matter. When an MP3 is encoded there is (mostly) a small delay added by the encoder, the size of this delay depends on the encoder and settings used. There is also some padding added to the end. To make matters worse when the MP3 is decoded, by something like the mpega.library, a further start delay is introduced. These delays are not always clean either, they can contain encoding and decoding artifacts.

I bought an MP3 Album from Amazon a week or so ago, and the gaps between tracks when playting with TuneNet were enough for me to look further into this.

Cheers,
Bean.

@bean

OK, thanks for the info. As far as I remember, the trick with Blade encoder is to move the boundary between the two audio tracks so that the "cut" don't fall in the middle of an mp3 frame. This trick is almost impossible to notice and works fine with TN gapless playing mode, but agreed, it alters the track lengths and may not be acceptable for on-line music stores, so that's probably why you have to deal with the issue you describe.

@bean

after several tests, I've found some cases that tunenet with the new mp3cast repeats the final part of a song like it's in an infinite loop. Dunno how I could help you better with this, I could even email you one of those mp3s to take a look if you wish. Let me know.

@Vulture

I'll take a look. In the meantime please check your PM.

Cheers,
Bean.

@bean

I've noticed the same problem that Vulture has.

@Valiant

Ah ha - I can recreate it. BRB

EditFixed. Going up shortly..

Cheers,
Bean,

@bean

Version 1.17

http://tunenet.co.uk/download/MP3Cast-Experimental-1.17.lha

Let me know how you all get on.

(Don't forget to stop and quit TuneNet fully before updating)

Cheers,
Bean.

@bean

There's something wrong, as a three minute track is showing up as 27m10s. Just checking back with the original mp3cast see if it is the same there.

(edit)

Original MP3Cast shows the track times correctly as 04m38s and 04m42s respectively. The gapless one shows them as 27m10s and (I forget but think it was) 27m17s.

Neither MP3 shows as being a gapless one in info. IIRC the track between these two was cut short but can't be sure on that.

@Chris

Is it just one track, lots, or all?

Once playing does the slider also show 20 odd mins, or does that sort itself out whilst playing?

Cheers,
Bean

@bean

At least two files (both encoded at the same time with the same options), TuneNet continues to play for the stated 20 mins (or I assume it does, I only waited a minute or so after the track finished). I've sent you a "faulty" MP3 by email.

@Chris

Thanks for the file. I realised what the problem was about 2 seconds after loading the file into FileX.

The issue is now resolved and I'll release after running through my test list.

Cheers,
Bean.

@bean

Not that I'm trying to break any records for posts in one day ...

http://tunenet.co.uk/download/MP3Cast-Experimental-1.18.lha

Let me know!

Many Thanks,
Bean.

@bean

OK, looks like the last version did the trick, but there is one more version for you all to try.

This version attempts to fix the problems people had with continueous low buffer situations and perhaps even the issue when switching stations where there was some erroneous cross over (I can't be sure I could never reproduce it).

http://tunenet.co.uk/download/MP3Cast-Experimental-1.19.lha

Let me know how you get on..

Cheers,
Bean.

@bean

At least it isn't playing the songs randomly now; it's playing them straight backwards in the list order.

@Valiant

?

Are you sure you haven't got shuffle play enabled, or have reordered your list by clicking the list headers? The plalist will play according to the position number (1st column), unless shuffle play is on.

The plugin can't affect the order of play, so can you check and let me know?

Cheers,
Bean

@bean Quote:
While (at the moment) I wasn't able to get the OLD plugin to permanently (or repeatedly) switch to the previous radio station, it was still having one brief "switch away" before playing as expected.

And the NEW plugin makes no difference to that.

But I just tried increasing the Radio's buffer from 32KB to 64KB, and that seemed to fix that issue. I'll have to see if that helps with the worse radio problems.

@ChrisH

If you get a chance can you put your buffer settings back to 32KB and see if you get less buffer critical and buffer low situations than you did before?

I'm not so sure that the old plugin was fully expunged when you did the tests, so if you could try again from a fresh reboot that would be great.

Thanks,
Bean

@bean
Looks like reboot was needed! With the new version I don't get any glitches at all, even with a 16KB buffer.

@bean

Hi - I installed the 1.19 version of the mp3cast plugin.
It works great here - no gaps any more!
Fantastic work - thank aou very much.

Andi

Sam440 - AmigaOS4.1U1 - ATI 9200 SE gfx board

Strange that I have the opposite effect on my sam440ep/OS4.1.1 system:
I still revert to the 1.14 MP3Cast-plugin, 'cos all the newer ones (1.17 - 1.19) give me gaps an hangs while playing 192kbit MP3's from Harddisk! Are there special settings I have to do?