Certain J2ME apps try to load audio streams without giving an explicit content type

[AShiningRay]

Some gameloft games like Gangstar Rio and Jurassic Park try to load audio streams without supplying a content type to go along with it, and since FreeJ2ME doesn't have a case to try and load those, it simply ignores and says it doesn't have a player for them:

But on my old Huawei G6608 (dead as of a few weeks), Gangstar Rio definitely played some SFX cues for vehicles, combat and etc, cues which are completely absent in FreeJ2ME, and i knew for a fact that it should be either PCM or ADPCM Wav since that phone had wonky support for AMR types... so i went in and added some code in order for FreeJ2ME to at least try to load those streams.

Sure enough, after adding some code to try and load those type-less streams as either midi or wav, which are the only players we have at the moment, Gangstar Rio now loads and plays its WAV SFX properly:

While Jurassic Park fails to load as either:

In Jurassic Park's case, it could be that this first stream is actually empty (it's loaded before the user even enables or disables audio for one), or from a format we don't yet support such as AMR or MP3... baking support for dumping those streams into files would help debug issues like these, and more... i wonder if that could work out, FreeJ2ME seems perfectly capable of doing that due to how it's built.

[recompileorg]

On Jurassic Park, if we could dump the stream data, we could probably figure out what format it's trying to use.

We could also try to do some type detection. Identifying wav/adpcm/midi is easy enough. Some other formats we might need to try to parse first. For example, I wrote a thing that can (mostly) convert the weird format the music Munkiki's Castles uses (it's a variant of a Nokia Ringtone format) to MIDI some time back, but there's no quick way to tell the type from the data.

[AShiningRay]

On Jurassic Park, if we could dump the stream data, we could probably figure out what format it's trying to use.

Just got a few minutes to implement a basic dumping function into FreeJ2ME, and only a single stream fails to load in Jurassic Park: The dumped file doesn't appear to be a valid format at all:

FFMpeg also fails to determine what it is. stream18.zip

On another note... dumping support on FreeJ2ME would be incredibly useful for devs and users alike, it's much easier than dealing with encryption and obfuscation in some jars, and it might even allow users to load up custom graphics, audio and etc if done right... as long as the dump/load sequence is the same, it should be easy to replace those assets and load up custom ones per-app. Well, that's an exercise for another day.

[recompileorg]

That's very true. It should be possible to "hijack" a load and substitute custom graphics, sound, etc.

Looking at the dumped stream, there isn't much there, though that should make it reasonably easy to decipher. It's short, so here's all of it:

00 23 01 01 01 01 01 01 01 FF FF 00 00 00 00 FF FE 00 FF 00 FF 00 00 00 00 FE FE FE 00 00 00 FF 00 FF FF FF FF

The first two bytes interpreted as a big endian int16 match the length of the remaining data, which is pretty common in older formats. It's also possible that the second byte alone is the length, like in a CLI Icon message. There's not much here, so the only think I imagine it could be is something like a ringtone, though there are quite a few possible formats it could be, with no easy way to tell the difference.

The versions of Jurassic Park that I have don't seem to have this file or anything really like it, though it looks like there's some annoying obfuscation happening. What version were you using?

[AShiningRay]

The versions of Jurassic Park that I have don't seem to have this file or anything really like it, though it looks like there's some annoying obfuscation happening. What version were you using?

Currently testing on this one: 320x240 Screen Res (probably for the Nokia C3-00 though i can't confirm) MIDlet v1.2.2 MD5 8a9e5962bb9a34c1c799f5451575830c Weighs in at 6.525.203 bytes