Excessively high values for Sound.length [Android]

I’ve been struggling with this error for some time and haven’t been able to get any help through Github or Twitter. Really hoping to resolve it since it’s holding up the Android launch of my app.

When I retrieve a sound with Assets.getSound() on Android, the length property of the sound is set to values that don’t represent anything close to what they should. One sound reports a length of 1.496212235e+248 – if measured in milliseconds, this is many times the age of the universe.

My haxelib is up to date.

actuate: 1.7.0 1.7.1 1.7.2 [1.7.5]
format: 3.0.5 3.1.1 [3.1.2]
haxelib_client: 3.1.0-rc.3 [3.1.0-rc.4]
hscript: 2.0.1 2.0.3 [2.0.4]
hxcpp: 3.1.30 [3.1.39]
hxlibc: 1.0.0 1.1.1 1.1.3 [1.1.4]
hxtools: [1.1.6]
lime-tools: 1.2.1 1.2.5 1.2.6 1.2.7 1.2.9 1.3.0 1.3.1 1.3.2 1.4.0 1.5.6 [1.5.7]
lime: 0.9.5 0.9.6 0.9.7 1.0.0 1.0.1 2.0.0-alpha 2.0.0-alpha.5 2.0.0-alpha.6 2.0.
0-alpha.7 2.0.0-alpha.8 [2.0.0-beta]
openfl-bitfive: 1.0.5 1.4.2 2.0.0 [2.0.1]
openfl-compatibility: [1.0.1]
openfl-html5-dom: 1.1.1 1.2.0 1.2.1 [1.2.2]
openfl-html5: 1.0.5 1.1.0-beta [1.4.2-beta]
openfl-native: 1.2.2 1.2.3 1.2.4 1.3.0 [1.4.0]
openfl-nme-compatibility: [1.0.2]
openfl-samples: 1.1.0 1.2.0 1.2.1 1.3.0 [2.1.0]
openfl: 1.1.1 1.2.0 1.2.1 1.2.2 1.2.3 1.3.0 1.4.0 2.0.0 2.0.1 2.1.0 2.1.0-beta 2
.1.3 [2.1.5]
tjson: 1.1.3 1.1.4 1.2.1 1.2.3 [1.3.0]

Hi Jacob!

What sound format(s) are you using? I you are using wav, you could always work around by deviding the data lenght with sample rate… Maybe this approach could be used also for fixedrate mp3 files.

Hi, I responded to you on Twitter already, but might as well do it here as well to keep info in the same place.

I’m only using ogg vorbis, which has been working fine on desktop (Windows/Mac/Linux C++) builds. I thought I’d read that OpenFL on Android will no longer support mp3 files?

Ok. I guess that it would be possible to calculate the sound length from the ogg header info. I can do some tests on this later this week…

I thought I had fixed this problem, do you know if the sound is streaming or not, does it definitely occur only on Android, not the desktop? Does it work differently in the new release than it did before?

Definitely Android only. I can’t test at the moment but I don’t know if this affects streaming sounds. It definitely affects sounds that are fully buffered.

Recently OpenFL updated so that sound lengths were given in milliseconds instead of seconds, and I modified my project accordingly. I don’t know if that was when it broke on Android since I hadn’t been able to test for some time for other reasons.

Any update on this? I hate to bump but it’s been two weeks and the lime update that came out recently didn’t do anything to fix this issue.

I remember looking into this and making fixes, but if it’s still occurring on Android, then I think the best solution is to do an #if android conditional in the openfl._v2.media.Sound class to return the correct length, do you think this is something you would be able to test on your side? I can integrate in your patch after it gives you the right values :slight_smile: