Open alexolivan opened 3 years ago
ElvishArtisan
commented
3 years ago Interesting idea! I've always thought of PAD being first-and-foremost an audience-facing data feed; the thought of including Rivendell internal state that would have meaning only to station staff frankly never occurred to me. It would certainly be doable, but I'd be interested to hear a use case where it would actually be used.
alexolivan
commented
3 years ago It would certainly be doable, but I'd be interested to hear a use case where it would actually be used. Sure... I could explain many, but probably too long to write here (and probably I'm going to go too long anyways trying to explain) I recognize the perspective of the classic FM radio network point of view, but, for a moment, just think about radiostations that never use FM, or their bussiness are 60 or 70% coming from streaming and podcast (for World audience) and barely 30% from the classic FM stations advertising model.
In my job, many of our customers are leading (literally) World Ibiza electronic music stations, and some of leading Electronic music stations in Spain (Barcelona, Fuerteventura, and many others).... Their audience can peak 80% international, 20% Local. And, although the main body of content is generated during the summer season, they keep high audiences all over the year worlwide. Their incomes come mainly from ad insert, preroll and midroll in audio (and video!) streaming, podcasting, web players and mobile devices, and also from content rights selling. Decision-makers have shifted from old-school FM managers, to younger big-data analysts, web managers, community-managers and all that crazy/cool new-wave profiles...
And they think different. For them the radio internals DO MATTER: They use 'visual' or 'video' radio solutions to broadcast their shows from a well-known Disco beach-terrace, From a famous Hotel swimpool terrace, from the nice little port of some place, from a yatch sailing the coast (really!) ... even on the studio, they care about how it looks (and when there's no live show, they put fixed camera images of Dawn, Sunrise, The city SkyLine, etc, from a Hill near the coast, a building top... things like that...they care very much on that). Famous interational Dj do participate either as guests, or as fixed season partners for certain show.
They want this info, this data to be known, because is relevant, because its ALL bussiness. They even sell rights of using high quality, dedicated non-add video/audio signal to be used in exclusive clothing shops, Gyms, Bars, WorldWide... very crazy...
For example: someone in Berlin, today, on subway, going to job, wants to remember the feel of his August trip in Ibiza, in Mallorca, In Fuerteventura, Barcelona, etc he/she would look at itunes, tune-in or other aggregators for looking for the top Radio Stations there... As he/she tunes on the stream, they definitely want to communicate not only what is the current playing tune (so it could be purchased in iTunes) this is not enough: They need to tell the listener that he/s tunning Program XXXXXX , live from Hotel YYYYY, with Suprstar Dj ZZZZ 'in da mix', scheduled from 09:00 to 10:00 or/and whatever data they want based on the current moment. They want the user to hook to the radio show directly... They want him/her to get rid of tune-In, iTunes, Amazon Alexa, Google or Apple devices, and go to the website, to download the official app, to subscribe to the show podcast, to join the facebook group, etc, etc so he/she get their ads. They want him/her to want to book the same destination next year. To go to certain Hotel. To go to certain Disco, etc, etc... And this is hard to do with just artist - tittle
Data is gold. And the automation system database is a mine. How they do currently? ... mostly through codes and an external database (data duplication...). They print an alphanumeric code on every song title, or even completelly get rid of artist / title and just put the code on the metadata as title. In some scenarios, they let Javascript web player and mobile player libraries coded to intercept the metadata code and query the radiostation web-backend to query for the actual metadata (and they don't like this .. its inefficient , troublesome and laggy) Others do use that approach with a private master intermediate streaming server, and use a program to render correct metadata and update CDN streaming metadata (which creates further delay/audio-video sync) Sometimes their backend-system queries the automation system DB for metadata, but often, they give up and maintain a separate database (usually on their web site backend) where they store all the desired metadata, and use just the codes fromthe automation system to time-sync and update metadata.
The thing is that, at the en of the day, it is the automation system who rules, because it is the source of truth. It is who plays, so it decides What, When, for how Long, and under which Conditions (The logmanager model).
Another example based on a real case, on what they actually work hard to do because automation systems not always do is the cover/image realtime updating... They love that. They struggle for having a web server that always serves an image, on the same URL, which precisely, just on time, updates/syncs with the current playing CART's metadata image (album cover, show flyer, or whatever image you asociate with the content).
ElvishArtisan
commented
3 years ago Data is gold. And the automation system database is a mine.
Indeed. This is a drum that I too have been beating for many years. It's one of the reasons that I'm such a fan of HLS Live Streaming: namely, the very rich ontology of metadata made possible by the use of ID3v2.4 tagged synchronized updates. The PyPAD plug-in that ships with GlassCoder is capable of much more than just the default iTunes schema; the entire ID3 field vocabulary is there for custom schema extensions. Stopping at just the basic 'Artist' - 'Title' has never made any sense to me. However, I would never have thought that internal values from the scheduling engine would be useful in this context.
Thank you for the detailed response!
Hi.
Being sys/network manager for streaming services, I realice how much customer appreciate rich meta-data on their streamings. Here in Rivendell, for streaming, I found every piece of valuable metadata for the CARTs reachable from pypad scripts for Now and Next... But I miss being able to put/get station's itself metadata from/to the database.
I think it would be great if we could have an aditional, user-defined, metadata text field for the event, clock (and eventually even grid and/or station) entities/models/classes (probably the 'easy' part) that could be reached from pypad scripts (I bet that would be the hard part). The goal would be to enable any level of radiostation metadata directly in and out of the automation system.
So, for example, provide I'm using the classic artist - title metadata pattern (I think its %a-%t from memory, not sure...) If I would have a Clock aditional meta field with a value such as 'Dj Foo Morning Show 09:00 - 10:00' reachable as, let' say %X And at event level (where I could force a certain scheduler code) a metadata field valued as '(Tune of the week!)' as %Y Then, a metadata pattern like %X %Y %a - %t would produce a fancy stream metadata: Dj Foo Morning Show 09:00 - 10:00 (Tune of the week!) someartist - sometitle
Right on time, Right on moment, right from the database
By having metadata in and toghether with the different layered station model (Station,Grid,Clock,event... CART) the user could have very different combinations with plenty of granularity... from not using any at all (so, like now) , to being able to communicate to audience very rich metadata about the radio-station itself (beyond the actual tune).
Cheers.