JMF vs Javasound (with mp3spi)

I think this is really two bugs:
1) Duration occasionally hangs with result as "UNKNOWN".
2) MP3 support fails on some types of MP3s.

Duration hanging issues have, AFAICT, been fixed as of SVN 20110403.
On that version, at least, I haven't experiences MP3 failures either, however, I'm yet to prove this with the files you sent due to problems with my specific chipset, see https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/759338

I think it would make sense to split this question into two bugs as listed above and deal with them separately.

Additionally, it should be noted that Duration needs fail cleanly, for example, in streams that have no known length, such as Live-RTSP.

In relation to adding extra library requirements, I have no issue with adding them under certain restrictions:
a) They have to be compatible with the GPL license.
b) They have to work cross-platform, at a minimum Windows, Linux, MacOSX (our current support level)
c) They have to be relevant to that section of code.

If, for example, they are actually an expansion, then I think they should be shipped as an optional extra (a "suggests" line in Linux packages, a tickbox in the Windows installer).

One example of this is the JMF MP3 plugin. While most people would want it (and the default in the WIndows Installer is set to "on"), it's technically not a core component and does not affect Flywire's ability to run. It just expands the codecs available to it.

Also, I think when choosing libraries to include, we should prefer, in order of preference:
- Stability (Has the library proved itself to work)
- Completeness (Can they provide complete support for a codec/feature or just parts of it)
- Size (Can the library to less with more)

Yeah, I didn't file this as a bug because I couldn't really define it - but those two seem pretty much on the money. Though if one fails, the other is ultimately true as well.

I compiled the current version under Windows XP SP3, though without the JMF MP3 plugin installed, as I have historically had more problems with it than without it on the build I have in the studio. I will test this tonight to see if the current build can work with the JMF plugin, instead of SPI.

Agreed on the streaming comment, we need to detect a stream and handle as appropriate.

Can I also just confirm that this is still the current repository - https://www.bentokit.org/svn/flywire/branches/0.2/ ?

Ok, I have done some testing. The file in question can be found here - http://dl.dropbox.com/u/21993125/S16%20-%20CHROMATICS%20-%20Circled%20Sun.mp3

I have one mp3 that changes it's duration dramatically under each scenario. It is tagged with ID3v2.2.0 - which was the informal standard drafted in 1998. Even though this mp3 was encoded with iTunes 9.2.1 which is only about 12 months old - sometimes Apple confuse me. It also has an embedded image using the PIC frame for this ID3 version, which I am _assuming_ is generating the issue.

Scenario 1 - No SPI; No JMF MP3
Length is displayed as 54:50:36
Player is not realized - mp3 (obviously) does not play.

Scenario 2 - No SPI; JMF MP3 Installed
Length is displayed as 42:15
Player is realized - mp3 does not play.

Scenario 3 - SPI added to classpath and duration method modified. (JMF MP3 still installed, but is irrelevant to this scenario)
Length is displayed as 04:07 (the correct duration as displayed in VLC/iTunes)
Player is irrelevant.

So while the JMF MP3 plugin does detect the mp3, it still does not handle it properly. This is using the 0.2 branch rev. 93 WIN XP SP3.

I'm going to have a crack at making a Player based off Javasound over the next few days to see how it goes.

No assumptions required, I stripped the ID3 tag and under the conditions of Scenario 2 above, the file duration is detected correctly and also plays correctly.

https://www.bentokit.org/svn/flywire/branches/0.2/ is the current
repository, although I would suggest using version 94 because I think 93
had a cosmetic bug (unless you hadn't noticed the slider and
countdown....um....didn't)

One other thing to point out is that the current versions have Player
State Highlighting which currently means:
Grey - Media never touched
White - No player active
Yellow - Player Realized but not Prefetched.
Orange - Player Prefetched and Ready to Play
Green - Player playing
Red - Player failed to realize or prefetch.

These colors may be adjusted/removed/hooked into a preference switch at
a later date. They're really only for debugging.

That work on ID tags affecting duration is interesting. I think we
should maybe start a repository of media that causes Flywire to fail,
that way I can use them to write code to allow Flywire to handle
scenarios involving dodgy media, and Ken can use them to test with, too.
 Obviously we can't put copyrighted media online, however if we could
create media that has the qualities required to make the failure happen
then that would be a greatly beneficial library to have.

A media library is obviously useful for testing (we could start here: http://www.pscode.org/media/), but _whatever_ path we go down to fix this problem, then I think it needs to be a smart fix at the root of the cause. I would prefer not to have to hack around dud media, but rather have a working media library that is robust enough to handle common (ie. iTunes) media.

It seems from Chris' tests that an image embedded in the mp3 ID3 tags is causing the error. I had suspected this might have been the case but never tested it.

I'm not going to pretend to understand the pros and cons of the underlying architecture, but from what I have gleaned from the two of you, JavaSound can't easily provide ongoing state information from multiple players at a time, while JMF can.

Tudor has suggested that because the problem is MP3 related, we should do some tests with FFMPEG and see if this fixes our problem. If it does, then perhaps we should look at using FMJ (which uses FFMPEG) as a drop-in alternative to JMF.

I am going to create the bugs listed in the discussion above.

Thought I'd better drop in an update on this.

I haven't done much over the last few weeks, but I have made some headway into a pure Javasound player. It currently detects, adds and plays media - it also rejects unplayable media from the outset. I won't commit these changes yet, as they aren't exactly cosmetic. If we would like to make a branch, so that there is a history of my changes, that's cool - I just don't want to break the current stream with my experiment.

Pros:
Much more lightweight than JMF and comes standard in the JRE.
Ability to extend to (theoretically) any file format through the use of an SPI. (MP3SPI from javazoom has been tested successfully) This means if there were, hypothetically, multiple ogg/vorbis plugins available, the user/administrator could choose whichever they preferred.

Cons:
Without any SPIs installed, only native support for WAV, AIFF, AU (could be a pro, depending on the conversation).
Requires us to maintain our own player class.

--

I read that the JMF performance pack uses java sound as it's playback method - but try as I might, I couldn't get it to use an SPI. I'm guessing that it isn't possible, so I'm going to press on and see if I can mimic the abilities of the 0.2 branch in this version.