Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 19, views: 20.980 •

Google heeft aan zijn native development kit voor Android 4.0 een mogelijkheid voor ontwikkelaars toegevoegd om direct toegang te krijgen tot raw audio streams. Hierdoor kan onder andere drm worden toegepast op audiostreams.

Met de nieuwe tools kunnen ontwikkelaars in Android-toepassingen voor Ice Cream Sandwich onder andere  eigen decoders toepassen die gecomprimeerde audiobestanden omzetten naar pcm-audio. Ook kunnen applicaties direct audiobestanden versleutelen, bijvoorbeeld voor drm-doeleinden. Google gebruikt voor de verbeterde toegang tot audio-streams OpenMAX AL, een interface in de programmeertaal C van het Khronos-consortium.

De nieuwe tools zijn onder andere interessant voor bedrijven die een applicatie willen uitbrengen voor het streamen van audio en daar - al dan niet noodgedwongen - drm op willen toepassen. Ook voor Android-toepassingen die audiobestanden manipuleren zijn de nieuwe toevoegingen aan de software-toolkit nuttig.

De uitbreidingen op de native development kit van Android 4.0 zijn niet afhankelijk van een bepaalde chipset. Enkele drm-modules die in Android 3.0 werden geïntroduceerd, zijn ook niet gebonden aan specifieke hardware, maar deze modulaire drm-modules bieden geen low level toegang tot audiobestanden. Hierdoor zijn de manipulatiemogelijkheden en de robuustheid van de versleuteling beperkt.

Reacties (19)

Als dit uiteindelijk kan leiden tot meer interesse van de muziekbusiness om alternatieve modellen zoals Spotify en wellicht Google Music: streamen vanuit te cloud, te implementeren op hun collectie, ben ik blij met de ontwikkeling. Het smaakje 'beperking' zit er wel in met DRM. Maar Spotify gebruikt toch ook een soort van eigen codering? In hoeverre is dat vergelijkbaar?
Apple iTunes store gebruikt al geen DRM meer voor muziek, lijkt me stug dat Google Android dat nodig heeft. Zou de trigger 'DRM' uit het artikel verder dus met een korreltje zout nemen. :)
For example, media applications can now retrieve data from any source, apply proprietary encryption/decryption, and then send the data to the platform for display.
Rechtstreeks van google zelf: Android Developers Blog

Over DRM zelf hebben ze het dus niet, maar encryptie is wel degelijk mogelijk.
Dat iTunes geen DRM meer gebruikt is omdat je de muziek zelf aanschaft en (gelukkig) bijna iedere aanbieder nu denkt vanuit de notie dat je dan ook zelf moet kunnen besluiten waar je de muziek mee afspeelt.

Echter, bij streaming toepassingen is er (in mijn ogen terecht) wel degelijk nog sprake van DRM.

Zo kan je met Spotify Premium je playlists ook offline beschikbaar maken voor op je Android of iOS device. In die gevallen is DRM nog steeds vereist.

Overigens, als je met Spotify ervoor kiest om het liedje te kopen, dan krijg je 'm ook gewoon drm-loos in mp3 formaat aangeboden.

Maar DRM kan dus nog steeds een belangrijke trigger zijn.
Apple iTunes store gebruikt al geen DRM meer voor muziek
Wel voor audiobooks en video.
Goeie zaak! Google is goed bezig! Nu heb ik wel het idee dat Android wat ndk en sdk betreft op veel punten achterliep op iOS.
Er is trouwens een verschil tussen Native Development Kit en Standard Development Kit. De titel van dit artikel is dan ook feitelijk onjuist, deze moet luiden "Vernieuwde Android-ndk biedt toegang tot raw audio-streams".

De link in het artikel zou dan ook naar de ndk moeten verwijzen en niet naar de sdk.
http://developer.android.com/sdk/ndk/overview.html

Het lijkt me wel duidelijk dat Google hiermee aan wensen van (toekomstige) partners wil voldoen. Benieuwd hoe Google Music straks gelanceerd gaat worden en of ze een kans maken tegen iTunes...

Edit: inderdaad, graey, je hebt gelijk. Verwarrend! Feit blijft wel dat de link verkeerd is, die moet wel naar de NDK verwijzen aangezien daar de specifieke functionaliteit staat beschreven. Is nu ook aangepast zie ik.

[Reactie gewijzigd door interslet op 13 november 2011 17:53]

Nee, want de SDK in de titel verwijst naar de algemene overkoepelende term Software Development Kit.
Daar zit bij Android dan een NDK bij in, maar die hoort bij de SDK. De S in SDK verwijst dan ook niet naar Standard. Zou ook raar zijn, aangezien Google de NDK-informatie als een subpagina van de SDK-informatie heeft staan, en de NDK bij de SDK inzit als je het download.
Naast voor bedrijven is dit ook interssant voor privacy-lievende gebruikers, zo kan je bv je audio/video streams beveligd streamen naar je mobieltje zonder dat je provider kan checken wat je aan t kijken of luisteren bent.
De headers van de gestreamde pakketjes zijn toch niet versleuteld? Het lijkt me dat anders de mediaspeler er geen raad mee zal weten.
Ik ben niet zo'n kenner op dit gebied maar, Betekend dit dat er betere software synthesizers gemaakt kunnen worden? beter in-app audio manipulatie?
Onder andere inderdaad. De nadruk ligt in dit artikel echter op encryptie met DRM-mogelijkheden. Dit is voornamelijk interessant voor content-aanbieders en co.

Google is pas sinds Gingerbread serieus met de SDK bezig. (Naar mijn mening!) Juist apps als software synthesizers blijven op Android vooralsnog achter bij iOS.
Met ICS gaat dit hopelijk snel veranderen. (Ik heb een Android telefoon, zoals je begrijpt)
Precies. Persoonlijk baal ik al bijna 3 jaar van de audio support van Android. Een simpele vocoder kun je alleen met truuks bouwen en dan nog zit je met een latency waar je U tegen zegt. Deze vernieuwing betekent dat Google na al die tijd eindelijk eens luistert naar developers en dat je nu zelf signal processing in je apps kunt bouwen. Ik verwacht binnen een paar maanden een reeks apps die je stem of ander geluid gaan vervormen, en de eerste goede muziek-record-apps. Wie weet komt er ooit nog eens een Cubase of Reason voor Android.
Lost dit de enorme audio-latency op? Want nu is bijvoorbeeld elke drum-app waardeloos.
Google API's waren altijd makkelijk en erg high-level, maar dat betekent dat direct toegang tot audio hardware best moeilijk / omslachtig was. Deze API's zijn ideaal voor een project waar ik mee bezig ben, maar het is jammer dat ze dus (als ik het goed begrijp) alleen zullen werken op Android 4.0? Andere nieuwe API's werden nog wel eens gebackport, zoals de Fragments API (ideeal om 1 app te maken die er op telefoons goed uit ziet, maar op tablets wel handig gebruik maakt van het volledige scherm).

Ik moet audio streamen, maar het complete process moet beveiligd zijn tegen 'onderscheppen' of opslaan. Een MP3 streamen gaat dus niet zo maar, die moeten encrypted zijn. En dan niet gewoon over HTTPS, dan is het kanaal wel encrypted maar kan iemand die de URL weet nog steeds gewoon bij de daadwerkelijke MP3 / OGG komen.

Ik moet dus zelf de audio data downloaden, zelf een decoder bouwen en die on-the-fly de data decrypt. Dat is zonde, want zo maak je nooit gebruik van alle hardware-decoding mogelijkheden in het Android platform. De enige manier nu is om de bestaande Multimedia API te laten wijzen naar een bestaande MP3 file. Ja, dat kan dus 'heel handig' ook direct vanaf een HTTP:// stream zodat je het transport niet zelf hoeft te coden, maar als je nog 'een geintje' met de binnengekomen data wilt uithalen kan je er dus helemaal niks mee.

audio decoders bouwen in Java zelf werkt wel, maar is tergend traag (mijn Desire HD lukte het niet om realtime een MP3 te decoden met een pure-Java mp3 decoder die ik ergens had gevonden), dus moet je weer moeilijk gaan doen om data te downloaden vanuit Java, door te geven aan de NDK om daar te decrypten en te decoden, en dan de ruwe PCM data weer naar java over te hevelen om daar uiteindelijk aan de 'ruwe audio API' te geven van Android. Die gaat het waarschijnlijk weer doorspelen aan de NDK omdat de meeste API's daar in zijn geÔmplementeerd.

Alles bij elkaar een hoop overhead en een hoop nodeloos gecopy van data (en ruwe PCM data kan best wat data zijn in the end) en dat merk je toch wel in de response, voornamelijk op de oudere ARMv11 chipjes, en de batterij duur wordt er ook weer niet beter op.

Please please backport dit naar Android 2.1+ :)
Je geeft aan dat je duidelijk niet zonder encryptie kan, wellicht is het interessant om uit te leggen waarom. Uit je uitleg blijkt het een complex en niet erg makkelijk uit te voeren concept is op de huidige versies van Android. Waarom is het een zaak van leven of dood dat niemand die audio in zijn originele formaat mag bemachtigen?
Eisen van rechten organisaties
Dit is inderdaad een mooie ontwikkeling, alleen als er geen backport komt misschien wel over anderhalf jaar pas echt bruikbaar omdat dan pas de meeste Androids op > 4.0 draaien. Net zoals de meeste apps tegenwoordig niet meer Android 1.5 ondersteunen, of dat alleen doen omdat ze geen gebruik maken van functies die later pas zijn toegepast.

Min of meer offtopic:

Ik zie op de developers site van Android dat er ook een compleet nieuwe market komt binnenkort :) Ziet er goed uit!

Op dit item kan niet meer gereageerd worden.



Populair:Apple iPhone 6DestinyAssassin's Creed UnityFIFA 15Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox OneAsus

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013