Hello ! I'm wondering if there is a way to display the current id3 track info on radio streaming ? (info hosted on shoutcast or icecast server) Cheers,
Our web designer is away on a short holiday, so the earliest would be next week or the week after that, assuming nothing else takes priority before then.
At the moment it looks like we will be adding ringtone support to the existing Audio activity, but the new Radio activity (with playlist + SHOUTcast server support) is probably going to be a premium feature.
Our web designer is back, it sounds like we're putting out another activity first (the photo one), in the meantime I'm putting some finishing touches on the Podcast activity.
> Will you also be compatible with Icecast AACplusV2 streams?
Icecast streams yes, as for AACplusV2 it depends on the Android device; Android does support AAC V2 codecs but only on Honeycomb or newer (so 3.1 and up).
@drfink > I also love to see that the new Audio activity (or Radio activity) displays the current id3 tag: artist, song title, and the cover!
It will grab the song title from the ID3 tag if a title isn't provided in the Andromo web settings or the playlist file -- the playlist file or Andromo track settings will always override the ID3 tags. There is some support for showing the artist, song title, year, etc. in the description field as well. Not extracting album covers, though, sorry. You can always use some cover art when designing your activity background, though.
@lorne: I'm not a Android programmer, but when I look at the specification of the Android class "MediaMetadataRetriever" described here (which your programmer probably uses to grab the ID3 tags), there's the Public Method "getEmbeddedPicture" (described here) which can be used to grab and display the embedded picture of the current streamed song.
We do use MediaMetadataRetriever to retrieve ID3v2 tags, although it has some quirks and limitations that make it a bit less reliable than I'd like.
Incidentally the docs describe it as being available since API 10 (Android 2.3.3) but after examining the Android source code and testing it on a few older devices, I determined that it was actually available in older versions of the OS.
The reason we aren't extracting album covers from individual tracks has more to do with a cost/benefit analysis based on the time it would take to implement it (adding multiple layouts, thumbnails, etc.) vs. the number of people it would affect. There don't seem to be many files out there with embedded artwork.
That isn't to say we won't consider adding it in the future. If you think we should add support for embedded pictures, add a question for it to our Google moderator page.
Thanks, lorne, for these information! Before I ask to add support for embedded pictures, I'm looking for using the new Audio activity/Radio activity - I hope it will be released soon!
The new Radio activity lets you specify a single URL, and you can choose one of three radio types:
Playlist - an .m3u, .pls, or .asx file containing links to individual audio tracks SHOUTcast Playlist - an .m3u, .pls, or .asx file containing links to SHOUTcast/Icecast server streams SHOUTcast Stream - a direct link to a SHOUTcast/Icecast server stream
The two SHOUTcast options basically just control whether the app will poll for SHOUTcast metadata.
Although it doesn't explicitly say so, the Playlist setting actually does support individual tracks, so you could specify a link to a single MP3, OGG, WAV, etc. although I'm not sure why you'd want to.
It will also support some RSS 2.0 feeds (e.g. iTunes podcasts) although we're adding a Podcast activity that is more appropriate for those.
As for the files referenced from the playlists, it supports any audio format that is supported by the device -- MP3, OGG, AAC, etc. depending on the version of Android on the user's phone or tablet.
@lorne: Hi, I want to "renew" this thread because I just want to know if you are planning to implement the feature "extract album covers from individual tracks" in the near future. You're $99/year offer is really cool, and I know that in May last year you said that it would not be worth "based on the time it would take to implement it vs. the number of people it would affect", because you think "there don't seem to be many files out there with embedded artwork".
Well, in times of itunes and other music online stores the listeners are accustomed to see covers from individual tracks, even in online radios.
I hope and wish you will change your opinion and offer this feature!
I wish I could but unfortunately I remain unconvinced.
The getEmbeddedPicture method does not apply to online radio streams; SHOUTcast does not use ID3 tags at all. We use different methods to get the current track, etc. for streaming audio, and the information provided is very sparse.
(There also happens to be a bug with MediaMetadataRetriever on Android 4.x that can prevent it from actually working for remote audio files, although as I mention above that class only applies to static audio files, not streaming radio.)
There is a way to provide links to image files in one of the newer SHOUTcast XML metadata formats, but (a) I've never seen it actually used, and (b) that data is only available using the server administrator's password, which would be unwise to transmit from an app.
It's something I will continue to investigate whenever I can, but I don't want you to have any false hopes about the likelihood of image extraction.
I agree it would be a nice feature if it were possible though.
There are some other approaches I might try at some point, but as I can't make any promises I wouldn't want that to influence your purchasing decision at all.
Comments
At the moment it looks like we will be adding ringtone support to the existing Audio activity, but the new Radio activity (with playlist + SHOUTcast server support) is probably
going to be a premium feature.
Will you also be compatible with Icecast AACplusV2 streams?
Incidentally the docs describe it as being available since API 10 (Android 2.3.3) but after examining the Android source code and testing it on a few older devices, I determined that it was actually available in older versions of the OS.
The reason we aren't extracting album covers from individual tracks has more to do with a cost/benefit analysis based on the time it would take to implement it (adding multiple layouts, thumbnails, etc.) vs. the number of people it would affect. There don't seem to be many files out there with embedded artwork.
That isn't to say we won't consider adding it in the future.
Will the streaming audio activity support custom http pls or ogg formats, or will it be shoutcast only.
The two SHOUTcast options basically just control whether the app will poll for SHOUTcast metadata.
Although it doesn't explicitly say so, the Playlist setting actually does support individual tracks, so you could specify a link to a single MP3, OGG, WAV, etc. although I'm not sure why you'd want to.
It will also support some RSS 2.0 feeds (e.g. iTunes podcasts) although we're adding a Podcast activity that is more appropriate for those.
As for the files referenced from the playlists, it supports any audio format that is supported by the device -- MP3, OGG, AAC, etc. depending on the version of Android on the user's phone or tablet.
Well, in times of itunes and other music online stores the listeners are accustomed to see covers from individual tracks, even in online radios.
I hope and wish you will change your opinion and offer this feature!
Thanks
The getEmbeddedPicture method does not apply to online radio streams; SHOUTcast does not use ID3 tags at all. We use different methods to get the current track, etc. for streaming audio, and the information provided is very sparse.
(There also happens to be a bug with MediaMetadataRetriever on Android 4.x that can prevent it from actually working for remote audio files, although as I mention above that class only applies to static audio files, not streaming radio.)
There is a way to provide links to image files in one of the newer SHOUTcast XML metadata formats, but (a) I've never seen it actually used, and (b) that data is only available using the server administrator's password, which would be unwise to transmit from an app.
It's something I will continue to investigate whenever I can, but I don't want you to have any false hopes about the likelihood of image extraction.
I agree it would be a nice feature if it were possible though.
There are some other approaches I might try at some point, but as I can't make any promises I wouldn't want that to influence your purchasing decision at all.