Problem with playing local mp3 files

I have a problem playing some mp3 files I have on my hard drive.

I use Project/addmedia to add the contents of a local directory to the playlist, but when I play them Tunenet plays the first second or two, and skips to the next track.

If I play them via multiview they play fine.

Other locals file play fine in Tunenet, and the only difference I can see is on the Tune tab, in Tunenet.
It shows the non-playing files as:

Quote:The files that play OK are showing as 128kbps, and 192kbps.

It would appear that tunenet cannot handle these 96kbps files. I can just re-encode tham at a higher bitrate, but I thought I ought to report the problem.

@Swoop

There is a huge amount of radio stations out there that
broadcast with 96kbs, hve you tried one of these?

I'll suspect the MP3's are broken, came about some of these
while my harvesting on the net, too

They seem to have some special encoded information which
you can read only on "Dollar Bill" machines.

Heck i even stumbled over an MP3 which has a virus on board.


Did these files play with earlier versions of TuneNet?

iirc multiview play through a datatype, TN through it's own
implementation of libmpeg!?

@Raziel

Quote:

Tunenet has no "mpega.library" as a requirement, the datatype uses mpega.library. mpega.library (afair) is libmad based, and should be pretty much reliable if proted correctly (I believe it is since it does play the files in questions).
I would create a mp3 file from some music cd and play it form the same HD. Preferably with same bitrate.

Jack

Hi @Swoop

I have a problem playing some mp3 files I have on my hard drive.

How did you aquire them? Downloaded files or stream recordings?
Used the Amiga or Windows?

Just trying to figure the input format.

@Snuffy

Quote:They were encoded on my laptop, from a CD I Own, and transfered to my A1 via a flash drive. They are date the 27/01/2007, so are not old. I do not know why they are encoded at 96kbps, but they play perfectly well with multiview, but tunenet skips to the next track.
They play in AmigaAMP, and looking at the tag info in AmigAMP it says the files are MPeg 1.0 layer 3, and the format is 44100HzJ-stereo, which is the same as the files that do play in Tunenet. The only difference is the bit rate of 96kbps instead of 128, and 192 for the files that Tunenet does play correctly.

If they would play on the Laptop, but not on my A1 I would agree that this would be an encoding/winblows problem, but as both AmigAMP and Multiview play the files on my A1 I assume the "problem" is in Tunenet.

Paul had asked for bug reports, and I thought this was possibly a bug. But I would be more than happy to find it isn't and that I have done something stupid, maybe with tunenet itself.

Hope that helps.

@Swoop

Quote:

Try to encode them with the same software at 128/192kbps and compare playbacks...

Edit:
btw: 96kbps(constant rate) isn't too good quality-wise. vbr is much better(older s/w might not support it)

Jack

@Swoop

I think it is a bug within TuneNet, either to do with the sensitivity of handling errors on a track, or a bug in the ID tag read code. I believe I've fixed both issues.

I have a deadline of the 16th of August to release a beta of TuneNet regardless of its current development state so if you can hold on until then you'll be able to try it out.

Thanks,
Bean.

@bean

Oww, 8 days, way to long.

@sundown

Yeah... looking forward to the update.

@sundown

way to long

Right, I keep forgetting California will fall off the US!


I have a deadline of the 16th of August to release a beta of TuneNet

Thank you, thank you!
Have a

@bean

Hi Paul

I have played about with this some more, and encoded some no my A1 at 96kbps, and they play fine in Tunenet.

Again looking for differences between the files there is an info button on Tunenet, and I get diff info on the playable, and non-playable files.

The newly encoded playable files show:-
Quote:
and the non-playable files show:-Quote:When I look at the ID3 tags using AmigaAMP, they both look correct, with the correct info in the correct fields, so I don't know why Tunenet shows different info between the playable and non-playable files.

Anyway I hope this helps.


[Edit on]
Paul
On re-reading your post #7, I think this is probably to do with the id3 tag read code that you mentioned. Hopefully it is now fixed. looking forward to the next release
[/Edit off]

Quote:
6 days...

@Swoop

I've fixed numerous bugs with my ID tag reader as well! Hoping it will have been fixed with the new release.

Cheers,
Bean.

@bean

Quote:

I had a quick look at the files using hexread in DOpus, and they seem to have the tag/file information in the header, and the tag also at the end of the file. Both look to have the same layout. I would expect you've already fixed this problem.

@TSK

Quote:

The deadline will slip somewhat - I've around 6 more hours of work - Not sure if I can fit it in between now and Thursday - I'll try.

Anyway, not too long now (though I've said that before!) - I think the phrase is: "When it's done!".
Bean.

Edit - Make that 4 hours to go now..

Edit - Probably another 2 hours now - It's taken me 6 hours already this week...

This is also basically about local file playback, well, stuff that doesn't matter really with net playback:

- the "reorder playlist" selection doesn't do anything
- not 100% sure of this, but shuffle mode seems to be a bit silly, since it does start to play a track as many times
- when shuffle is on and repeat is off (I think), the progress of the playlist sometimes breaks - not necessarily at the bottom-most item - suggesting the user to reshuffle

These with TuneNet from 15.1.2007, and latest OS4 (July update). I'm mentioning these partly because I'd like to hear if it's consistent with other people's experience or more rare, partly because I wouldn't mind hearing that they have been fixed in the current program code.

May the source be with you