Re: [RDD] Synchronizing carts and logs

[Fred Gleason]

On Jun 24, 2016, at 15:35, Sherrod Munday  wrote:

> I just came across a mention of the "Archive eXchange Format" ("AXF")
> specification from late 2014:
> 
> http://www.tvtechnology/com/news/0002/smpte-publishes-archive-exchange-format-standard/272423
>  
> 
> 
> I know it comes from the TV world instead of radio, and it pertains
> specifically to archiving content, but is there any sense to
> implementing a published standard from a different industry instead of
> a one-off?

It’s a bit apple-to-oranges WRT this discussion I think.  To read the 
description, it sounds quite similar to the tar(5) format, which already 
supports many of the same features.

Cheers!


|--|
| Frederick F. Gleason, Jr. |  Chief Developer |
|   |  Paravel Systems |
|--|
|  A room without books is like a body without a soul. |
| -- Cicero|
|--|___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Synchronizing carts and logs

[Cowboy]

On Friday 24 June 2016 03:35:45 pm Sherrod Munday wrote:

> I know it comes from the TV world instead of radio, and it 
> pertainsspecifically to archiving content, but is there any sense 
> toimplementing a published standard from a different industry instead ofa 
> one-off?

 In the original concept, it's not a different industry !

-- 
Cowboy
___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Synchronizing carts and logs

[Sherrod Munday]

On Tue, Jun 14, 2016 at 1:23 PM, Fred Gleason  wrote:

> Here’s an idea: what say we embed a copy of the relevant ‘cartList’ XML
> object (such as is currently generated by Rivendell's ListCart Web API call)
> in every file export?

I just came across a mention of the "Archive eXchange Format" ("AXF")
specification from late 2014:

http://www.tvtechnology/com/news/0002/smpte-publishes-archive-exchange-format-standard/272423

I know it comes from the TV world instead of radio, and it pertains
specifically to archiving content, but is there any sense to
implementing a published standard from a different industry instead of
a one-off?

--Sherrod
___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Synchronizing carts and logs

[Stan Fotinos]

Sounds great !

Stan




On 15 June 2016 9:05:00 pm AWST, Rob Landry <41001...@interpring.com> wrote:
>
>Yes, I like the XML idea, particularly if rdimport will recognize it.
>
>Then all we need is an analogous method to export and import logs.
>
>
>Rob
>
>-- 
>Я там, где ребята толковые,
>Я там, где плакаты "Вперёд",
>Где песни рабочие новые
>Страна трудовая поёт.
>
>On Tue, 14 Jun 2016, Alessio Elmi wrote:
>
>> +1 for XML! I think a good idea, considering a wider scenario, could
>be the
>> following:
>> i) The same xml output can be generated 'per-cart' when exporting
>single/few
>> audio files, but it could be also an alternative report format from
>> RDLibrary (one file with the whole list inside).
>> 
>> ii) The same xml can be used in addition with rdimport routine. When
>> importing 'test.wav' it would look for 'test.xml'. If there, it will
>fill
>> metadata accordingly (of ocurse it should expect a single-cut cart
>> template).
>> 
>> Alessio
>> 
>> Il giorno mar 14 giu 2016 alle ore 19:24 Fred Gleason
>>  ha scritto:
>>   On Jun 14, 2016, at 07:57, drew Roberts 
>>   wrote:
>> http://www.wavpack.com/
>>
>> "Uses ID3v1 and APEv2 tags for metadata (including
>> ReplayGain)"
>> 
>> Would that get us there?
>> 
>> 
>> ID3v1 is very consumer- and pop music-oriented, and thus is missing
>> many of the fields that are relevant for broadcasters —e.g. Agency
>and
>> Client.  APEv2 is more intriguing inasmuch as it includes a mechanism
>> for extending the field definitions, however, it does not seem to
>> enjoy very wide support.
>> 
>> Here’s an idea: what say we embed a copy of the relevant ‘cartList’
>> XML object (such as is currently generated by Rivendell's ListCart
>Web
>> API call) in every file export?  I see a number of advantages to this
>> approach:
>> 
>> 1) XML is a widely-supported format, with high-quality FOSS parsers
>> available for virtually every major programming language.
>> 
>> 2) The format is human-readable and would be largely
>self-documenting.
>> 
>> 3) The same parser code that reads cartList objects via the web
>> interface would also work here with little modification.
>> 
>> Likewise, we then extend Rivendell’s import tools (RDImport and
>> RDLibrary) to parse this same data structure, thus giving us a
>> high-fidelity path for transferring both audio and Rivendell cart/cut
>> metadata between systems.
>> 
>> For reference, here is a sample of the cartList object:
>> 
>> *** snip snip ***
>> 
>>   
>>     10004
>>     audio
>>     MUSIC
>>     American Pie
>>     Don Mc Lean
>>     100 Hits Party Classics
>>     
>>     
>>     
>>     
>>     
>>     
>>     
>>     0
>>     0:04:03.7
>>     0:04:03.7
>>     0:00:00.0
>>     0:04:02.6
>>     0:00:00.0
>>     1
>>     0
>>     2
>>     false
>>     false
>>     
>>     2016-05-31T08:20:23-04:00
>>       
>>         
>>           010004_001
>>           10004
>>           1
>>           false
>>           Cut 001
>>           
>>           
>>           
>>           243794
>>           2014-11-30T09:38:49-04:00
>>           
>>           
>>           true
>>           true
>>           true
>>           true
>>           true
>>           true
>>           true
>>           
>>           
>>           rdhost
>>           1
>>          
>> 2015-03-24T10:23:55-04:00
>>           49
>>           49
>>           2
>>           0
>>           48000
>>           0
>>           2
>>           0
>>           336
>>           244130
>>           -1
>>           -1
>>           243024
>>           244104
>>           -3000
>>           -1
>>           -1
>>           -1
>>           0
>>         
>>       
>>   
>> 
>> *** snip snip ***
>> 
>> Cheers!
>> 
>> 
>>
>|--|
>> | Frederick F. Gleason, Jr. |              Chief Developer          
> 
>> |
>> |                           |              Paravel Systems          
> 
>> |
>>
>|--|
>> |          A room without books is like a body without a soul.      
> 
>> |
>> |                                         -- Cicero                 
> 
>> |
>>
>|--|
>> 
>> ___
>> Rivendell-dev mailing list
>> Rivendell-dev@lists.rivendellaudio.org
>> http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
>> 
>> 
>>
>
>
>
>___
>Rivendell-dev mailing list
>Rivendell-dev@lists.rivendellaudio.org
>http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Synchronizing carts and logs

[Rob Landry]

I'm not comfortable playing linear audio files across the Internet, 
particularly from either Cape Cod or Block Island, where available 
bandwidth can vary wildly. The Block Island station runs rdairplay on a 
machine at its transmitter site with local audio and a local database, 
precisely to avoid dropout issues.


On the island, Verizon DSL or mobile broadcband from Verizon or AT are 
the only Internet options, and my understanding is that they all connect 
to the mainland Internet through a common (Verizon? ) microwave hop whose 
capacity is adequate for the island's year-round population of 1,000, but 
less so in the summer when it baloons to 10,000 or more.


Cape Cod may have a similar problem; our Comcast service there is 
nominally 20 Mbps (IIRC), but there are times when we have horrendous 
dropout problems when live audio from my client's Hyannis studio is routed 
to his Framingham (Boston) station. Those live broadcasts are either 64 
Kbps HE-AAC or 128 Kbps MP3.


Re: replication: neither the Hyannis nor the Framingham database can be a 
slave of the other. There are audio carts produced in Hyannis that run in 
Framingham and vice-versa. In theory, someone can record a newscast or 
feature and expect it to air 15 minutes later at the other facility.


The scripts we have work; my only issue is minimizing the headache at 
upgrade time.



Rob

--
Я там, где ребята толковые,
Я там, где плакаты "Вперёд",
Где песни рабочие новые
Страна трудовая поёт.

On Mon, 13 Jun 2016, Cowboy wrote:


On Monday 13 June 2016 04:57:44 pm Rob Landry wrote:

If someone at WSRO records a newscast in Rivendell, I want it to show up
at WBAS with the same cart number, metadata, and audio; and if someone
records a spot at WBAS, I want it to show up at WSRO.

Moreover, I also want logs generated at one station to be available at the
other.



How big are the network pipes ?
Common database/sound server ?
Replication, and rsync /var/snd ?

--
Cowboy

http://cowboy.cwf1.com

If you think the United States has stood still, who built the largest
shopping center in the world?
-- Richard Nixon
___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Synchronizing carts and logs

[drew Roberts]

On Wed, Jun 15, 2016 at 9:05 AM, Rob Landry <41001...@interpring.com> wrote:

>
> Yes, I like the XML idea, particularly if rdimport will recognize it.
>
> Then all we need is an analogous method to export and import logs.

+1

>
>
>
> Rob
>
>
>
drew
-- 
Bahamain Or Nuttin - http://www.bahamianornuttin.com

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Synchronizing carts and logs

[Rob Landry]

Yes, I like the XML idea, particularly if rdimport will recognize it.

Then all we need is an analogous method to export and import logs.


Rob

--
Я там, где ребята толковые,
Я там, где плакаты "Вперёд",
Где песни рабочие новые
Страна трудовая поёт.

On Tue, 14 Jun 2016, Alessio Elmi wrote:


+1 for XML! I think a good idea, considering a wider scenario, could be the
following:
i) The same xml output can be generated 'per-cart' when exporting single/few
audio files, but it could be also an alternative report format from
RDLibrary (one file with the whole list inside).

ii) The same xml can be used in addition with rdimport routine. When
importing 'test.wav' it would look for 'test.xml'. If there, it will fill
metadata accordingly (of ocurse it should expect a single-cut cart
template).

Alessio

Il giorno mar 14 giu 2016 alle ore 19:24 Fred Gleason
 ha scritto:
  On Jun 14, 2016, at 07:57, drew Roberts 
  wrote:
http://www.wavpack.com/

"Uses ID3v1 and APEv2 tags for metadata (including
ReplayGain)"

Would that get us there?


ID3v1 is very consumer- and pop music-oriented, and thus is missing
many of the fields that are relevant for broadcasters —e.g. Agency and
Client.  APEv2 is more intriguing inasmuch as it includes a mechanism
for extending the field definitions, however, it does not seem to
enjoy very wide support.

Here’s an idea: what say we embed a copy of the relevant ‘cartList’
XML object (such as is currently generated by Rivendell's ListCart Web
API call) in every file export?  I see a number of advantages to this
approach:

1) XML is a widely-supported format, with high-quality FOSS parsers
available for virtually every major programming language.

2) The format is human-readable and would be largely self-documenting.

3) The same parser code that reads cartList objects via the web
interface would also work here with little modification.

Likewise, we then extend Rivendell’s import tools (RDImport and
RDLibrary) to parse this same data structure, thus giving us a
high-fidelity path for transferring both audio and Rivendell cart/cut
metadata between systems.

For reference, here is a sample of the cartList object:

*** snip snip ***

  
    10004
    audio
    MUSIC
    American Pie
    Don Mc Lean
    100 Hits Party Classics
    
    
    
    
    
    
    
    0
    0:04:03.7
    0:04:03.7
    0:00:00.0
    0:04:02.6
    0:00:00.0
    1
    0
    2
    false
    false
    
    2016-05-31T08:20:23-04:00
      
        
          010004_001
          10004
          1
          false
          Cut 001
          
          
          
          243794
          2014-11-30T09:38:49-04:00
          
          
          true
          true
          true
          true
          true
          true
          true
          
          
          rdhost
          1
         
2015-03-24T10:23:55-04:00
          49
          49
          2
          0
          48000
          0
          2
          0
          336
          244130
          -1
          -1
          243024
          244104
          -3000
          -1
          -1
          -1
          0
        
      
  

*** snip snip ***

Cheers!


|--|
| Frederick F. Gleason, Jr. |              Chief Developer            
|
|                           |              Paravel Systems            
|
|--|
|          A room without books is like a body without a soul.        
|
|                                         -- Cicero                   
|
|--|

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev


___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Synchronizing carts and logs

[Fred Gleason]

On Jun 15, 2016, at 06:46, drew Roberts  wrote:

> it would actually be 1.wav at the master location
> and it would also be 1.wav at the secondary location
> 
> 1.wav at the master would contain pcm data
> 1.wav at the secondary would contain mp2 data
> 
> At least that has been my experience so far with my limited efforts in this 
> area.

Exactly right.

Cheers!


|--|
| Frederick F. Gleason, Jr. |  Chief Developer |
|   |  Paravel Systems |
|--|
|  A room without books is like a body without a soul. |
| -- Cicero|
|--|

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Synchronizing carts and logs

[Fred Gleason]

On Jun 14, 2016, at 20:46, Tim Elwell  wrote:

> Fred, would it be possible then to allow the audio to change formats between 
> RD systems with this? For example, if your primary was WAV audio, but you 
> needed to export to a different system that was mp2, would it be possible to 
> export the data from the WAV primary station and import it to the mp2 station 
> with all the correct information? In my brain it seems like it would, but 
> that's getting outside my brain's expertise level.

Yes, the metadata and the audio encoding format are completely orthogonal in 
this case.  All marker information is specified in terms of a absolute time 
offsets from the beginning of the audio data, so things like sample rate 
conversion will not affect it.

Cheers!


|--|
| Frederick F. Gleason, Jr. |  Chief Developer |
|   |  Paravel Systems |
|--|
|  A room without books is like a body without a soul. |
| -- Cicero|
|--|

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Synchronizing carts and logs

[drew Roberts]

Tim,

On Tue, Jun 14, 2016 at 8:46 PM, Tim Elwell 
wrote:

> On 6/14/16 12:23 PM, Fred Gleason wrote:
>
>> Likewise, we then extend Rivendell’s import tools (RDImport and
>> RDLibrary) to parse this same data structure, thus giving us a
>> high-fidelity path for transferring both audio and Rivendell cart/cut
>> metadata between systems.
>>
>>
>> Fred, would it be possible then to allow the audio to change formats
> between RD systems with this? For example, if your primary was WAV audio,
> but you needed to export to a different system that was mp2, would it be
> possible to export the data from the WAV primary station and import it to
> the mp2 station with all the correct information? In my brain it seems like
> it would, but that's getting outside my brain's expertise level.
>

We shall see what Fred says, but I am fairly certain this is a piece of
cake. I have dome something very similar already.



> snip...



> So, it would be nice to set it up in the primary wav system with all
> information and segue points (though, I'm not sure the segues would
> calculate right between formats), etc done there, then export the setup to
> the mp2 systems without having to keep two master systems (1 wav, 1 mp2) so
> everything is the same.


it would actually be 1.wav at the master location
and it would also be 1.wav at the secondary location

1.wav at the master would contain pcm data
1.wav at the secondary would contain mp2 data

At least that has been my experience so far with my limited efforts in this
area.


> And yes, I know hard drives are cheap, but connectivity in some places
> isn't, so transferring 8megs vs 40 megs makes a big difference when
> multiplied across many songs each week.
>
> Anyway, mostly still a curiosity at this point, but could make my life a
> lot easier for a project I've been working on for a while.
>
> Thanks for all the great work!
>
> Tim
>
> all the best,

drew
-- 
Bahamain Or Nuttin - http://www.bahamianornuttin.com

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Synchronizing carts and logs

[Tim Elwell]

On 6/14/16 12:23 PM, Fred Gleason wrote:
Likewise, we then extend Rivendell’s import tools (RDImport and 
RDLibrary) to parse this same data structure, thus giving us a 
high-fidelity path for transferring both audio and Rivendell cart/cut 
metadata between systems.



Fred, would it be possible then to allow the audio to change formats 
between RD systems with this? For example, if your primary was WAV 
audio, but you needed to export to a different system that was mp2, 
would it be possible to export the data from the WAV primary station and 
import it to the mp2 station with all the correct information? In my 
brain it seems like it would, but that's getting outside my brain's 
expertise level.


I have a use scenario that I've been trying to hash through for years 
and years and haven't found a good way to make it work. We want the 
primary in lossless wav format (so it can be used anywhere we have good 
reliable and cheap access), but have instances due to distant, expensive 
and slow connectivity that we need the smaller file sizes to transfer to 
remote sites of mp2 and all stations have the same cart numbers for 
easier log creation. So, it would be nice to set it up in the primary 
wav system with all information and segue points (though, I'm not sure 
the segues would calculate right between formats), etc done there, then 
export the setup to the mp2 systems without having to keep two master 
systems (1 wav, 1 mp2) so everything is the same. And yes, I know hard 
drives are cheap, but connectivity in some places isn't, so transferring 
8megs vs 40 megs makes a big difference when multiplied across many 
songs each week.


Anyway, mostly still a curiosity at this point, but could make my life a 
lot easier for a project I've been working on for a while.


Thanks for all the great work!

Tim
___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Synchronizing carts and logs

[Alessio Elmi]

+1 for XML! I think a good idea, considering a wider scenario, could be the
following:

i) The same xml output can be generated 'per-cart' when exporting
single/few audio files, but it could be also an alternative report format
from RDLibrary (one file with the whole list inside).

ii) The same xml can be used in addition with rdimport routine. When
importing 'test.wav' it would look for 'test.xml'. If there, it will fill
metadata accordingly (of ocurse it should expect a single-cut cart
template).

Alessio

Il giorno mar 14 giu 2016 alle ore 19:24 Fred Gleason <
fr...@paravelsystems.com> ha scritto:

> On Jun 14, 2016, at 07:57, drew Roberts  wrote:
>
> http://www.wavpack.com/
>
> "Uses ID3v1 and APEv2 tags for metadata (including ReplayGain)"
>
> Would that get us there?
>
>
> ID3v1 is very consumer- and pop music-oriented, and thus is missing many
> of the fields that are relevant for broadcasters —e.g. Agency and Client.
> APEv2 is more intriguing inasmuch as it includes a mechanism for extending
> the field definitions, however, it does not seem to enjoy very wide support.
>
> Here’s an idea: what say we embed a copy of the relevant ‘cartList’ XML
> object (such as is currently generated by Rivendell's ListCart Web API
> call) in every file export?  I see a number of advantages to this approach:
>
> 1) XML is a widely-supported format, with high-quality FOSS parsers
> available for virtually every major programming language.
>
> 2) The format is human-readable and would be largely self-documenting.
>
> 3) The same parser code that reads cartList objects via the web interface
> would also work here with little modification.
>
> Likewise, we then extend Rivendell’s import tools (RDImport and RDLibrary)
> to parse this same data structure, thus giving us a high-fidelity path for
> transferring both audio and Rivendell cart/cut metadata between systems.
>
> For reference, here is a sample of the cartList object:
>
> *** snip snip ***
> 
>   
> 10004
> audio
> MUSIC
> American Pie
> Don Mc Lean
> 100 Hits Party Classics
> 
> 
> 
> 
> 
> 
> 
> 0
> 0:04:03.7
> 0:04:03.7
> 0:00:00.0
> 0:04:02.6
> 0:00:00.0
> 1
> 0
> 2
> false
> false
> 
> 2016-05-31T08:20:23-04:00
>   
> 
>   010004_001
>   10004
>   1
>   false
>   Cut 001
>   
>   
>   
>   243794
>   2014-11-30T09:38:49-04:00
>   
>   
>   true
>   true
>   true
>   true
>   true
>   true
>   true
>   
>   
>   rdhost
>   1
>   2015-03-24T10:23:55-04:00
>   49
>   49
>   2
>   0
>   48000
>   0
>   2
>   0
>   336
>   244130
>   -1
>   -1
>   243024
>   244104
>   -3000
>   -1
>   -1
>   -1
>   0
> 
>   
>   
> 
> *** snip snip ***
>
> Cheers!
>
>
> |--|
> | Frederick F. Gleason, Jr. |  Chief Developer |
> |   |  Paravel Systems |
> |--|
> |  A room without books is like a body without a soul. |
> | -- Cicero|
> |--|
>
> ___
> Rivendell-dev mailing list
> Rivendell-dev@lists.rivendellaudio.org
> http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
>
___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Synchronizing carts and logs

[Fred Gleason]

On Jun 14, 2016, at 13:38, Cowboy  wrote:

> Further more, *should be* relatively easy to make it speak
> competing system, not that anyone would ever actually want to do that.

Outside of my scope.  :)

Cheers!


|--|
| Frederick F. Gleason, Jr. |  Chief Developer |
|   |  Paravel Systems |
|--|
|  There is only one thing worse than having your competitors trying   |
|  to inter-operate with your systems - and that is to have your   |
|  competitors *not* trying to inter-operate with your systems.|
|   --Alan(UK), GrokLaw.net|
|--|

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Synchronizing carts and logs

[Cowboy]

On Tue, 14 Jun 2016 13:23:08 -0400
Fred Gleason  wrote:

> thus giving us a high-fidelity path for transferring both audio and
> Rivendell cart/cut metadata between systems.

 Further more, *should be* relatively easy to make it speak
 competing system, not that anyone would ever actually want to do that.

-- 
Cowboy

http://cowboy.cwf1.com

There are two ways to write error-free programs.
Only the third one works.
___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Synchronizing carts and logs

[Fred Gleason]

On Jun 14, 2016, at 07:57, drew Roberts  wrote:

> http://www.wavpack.com/ 
> 
> "Uses ID3v1 and APEv2 tags for metadata (including ReplayGain)"
> 
> Would that get us there?

ID3v1 is very consumer- and pop music-oriented, and thus is missing many of the 
fields that are relevant for broadcasters —e.g. Agency and Client.  APEv2 is 
more intriguing inasmuch as it includes a mechanism for extending the field 
definitions, however, it does not seem to enjoy very wide support.

Here’s an idea: what say we embed a copy of the relevant ‘cartList’ XML object 
(such as is currently generated by Rivendell's ListCart Web API call) in every 
file export?  I see a number of advantages to this approach:

1) XML is a widely-supported format, with high-quality FOSS parsers available 
for virtually every major programming language.

2) The format is human-readable and would be largely self-documenting.

3) The same parser code that reads cartList objects via the web interface would 
also work here with little modification.

Likewise, we then extend Rivendell’s import tools (RDImport and RDLibrary) to 
parse this same data structure, thus giving us a high-fidelity path for 
transferring both audio and Rivendell cart/cut metadata between systems.

For reference, here is a sample of the cartList object:

*** snip snip ***

  
10004
audio
MUSIC
American Pie
Don Mc Lean
100 Hits Party Classics







0
0:04:03.7
0:04:03.7
0:00:00.0
0:04:02.6
0:00:00.0
1
0
2
false
false

2016-05-31T08:20:23-04:00
  

  010004_001
  10004
  1
  false
  Cut 001
  
  
  
  243794
  2014-11-30T09:38:49-04:00
  
  
  true
  true
  true
  true
  true
  true
  true
  
  
  rdhost
  1
  2015-03-24T10:23:55-04:00
  49
  49
  2
  0
  48000
  0
  2
  0
  336
  244130
  -1
  -1
  243024
  244104
  -3000
  -1
  -1
  -1
  0

  
  

*** snip snip ***

Cheers!


|--|
| Frederick F. Gleason, Jr. |  Chief Developer |
|   |  Paravel Systems |
|--|
|  A room without books is like a body without a soul. |
| -- Cicero|
|--|

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Synchronizing carts and logs

[drew Roberts]

Fred,

On Mon, Jun 13, 2016 at 2:52 PM, Fred Gleason 
wrote:

> On Jun 13, 2016, at 14:33, drew Roberts  wrote:
>
> I am not sure about all metadata, but WO puts things like artist and title
> in the file. When you import into another system, this comes along. (IIRC.)
>
>
> This has been true for Rivendell as well for quite some time.
>

I thought so, but I could not get the export going to check it out the last
time I needed so I worked things another way.

>
>
> It would likely be good if we had the option to leave the file name as
> cart_cut or change it to something like title_artist or artist_title.
>
>
> The main limitation with the current scheme is the relative paucity of
> available metadata fields.  For formats that offer transparent audio
> quality, you’re basically limited to WAV, which means BWF/CartChunk for
> metadata.
>
Have you looked at Wavpack?

http://www.wavpack.com/

"Uses ID3v1 and APEv2 tags for metadata (including ReplayGain)"

Would that get us there?


>  Not much there beyond Title, Artist and Client (although there is support
> for providing Start/End, Segue and Talk marker data, a facility which
> Rivendell takes full advantage of).  Various automation vendors have
> proprietary extensions that provide more fields, but those are pretty much
> limited to interoperation within that vendor’s product offerings (and
> Rivendell, which will read a number of those formats).
>
> While we could go down the road of inventing Yet Another One-Off Metadata
> Format, it’d far more useful to use something that is a bit more industry
> standard while also offering the ability to capture the full range of
> available fields.  Those may be incompatible requirements.  Any ideas?
>

Have an export option that writes out:

file.wav|flac|mp3 etc.

and

file.meta

where audio goes in the first and matching metadata in the second.

Thoughts?

>
> Cheers!
>
>
> |--|
> | Frederick F. Gleason, Jr. |  Chief Developer |
>
> all hte best,

drew
-- 
Bahamain Or Nuttin - http://www.bahamianornuttin.com

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Synchronizing carts and logs

[Robert Jeffares]

On 14/06/16 06:26, Rob Landry wrote:
Doing a database backup/restore once a day and rsync'ing /var/snd, as 
some have suggested, is impractical. 


With a little bit of organization you can extract from mysql everything 
you need to update "on the network" and still leave "local" carts like 
Weather Traffic Community Announcements etc untouched.


I operate three sites which get updated at :45 each hour using a shell 
script which extracts data from mysql which is rsync-ed to each client 
and imported into the local mysql. It's split and staggered.

I have had to make one amendment in 5+ years. Thats acceptable.
Ads and Promos get updated at the same time. All clients copy all audio; 
this provides backup I have had occasion to use.
Clients load News Weather etc at :55 so the local system has accurate 
material and durations.


Music for the following 7 days is updated early evening. No updates 
happen midnight -5am which is when logs are generated.


I have considered the multiple source option; at the moment all input 
[other then weather traffic news] goes to the master server.


If someone remotely produces audio they put it in the local dropbox and 
it gets rsync-ed back to base, imported, and distributed in the next update.


We have a series of long format programmes which are supplied as mp3's 
so they are distributed to each station and carted locally. Since the 
master sets the durations etc the database is accurate. Carting is 
logged and a copy of the log emailed to be checked for errors.


I thought about having a round robin update, which, while possible, is a 
bit cumbersome and just adds to the error potential.


I am in process of testing a VPN setup for voice tracking [I now have 2 
independent Broadbands here]  and have been investigating the mirroring 
of /var/snd and what is involved in keeping everything in sync.  I might 
say if the voice tracking works thats all I need. I think RD will grab 
enough audio for that to work over ADSL maybe not all that fast but fast 
enough.


Rivendell has been designed around one audio library serving multiple 
clients at a single site. Cloning a system is easy enough. Genetic 
Modification is a little trickier.


regards

Robert Jeffares

-- *Big Valley Radio*
64 Warner Park Avenue

Laingholm

Auckland 0604

09 8176358

0221693124

06 650 6087
___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Synchronizing carts and logs

[Cowboy]

On Monday 13 June 2016 04:57:44 pm Rob Landry wrote:
> If someone at WSRO records a newscast in Rivendell, I want it to show up 
> at WBAS with the same cart number, metadata, and audio; and if someone 
> records a spot at WBAS, I want it to show up at WSRO.
> 
> Moreover, I also want logs generated at one station to be available at the 
> other.
> 

 How big are the network pipes ?
 Common database/sound server ?
 Replication, and rsync /var/snd ?

-- 
Cowboy

http://cowboy.cwf1.com

If you think the United States has stood still, who built the largest
shopping center in the world?
-- Richard Nixon
___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Synchronizing carts and logs

[Alessio Elmi]

What about MySQL replication? Could it be useful? I know it has a variable
granularity (per table, per database and so on..)

Il giorno lun 13 giu 2016 alle ore 22:57 Rob Landry <41001...@interpring.com>
ha scritto:

>
> I can't speak for anyone else, but I'm not looking to export Rivendell
> cuts, but to have them show up on a Rivendell system attached to a
> different server.
>
> Say, for instance, my client has two radio stations which I will call WSRO
> (Framingham) and WBAS (Hyannis).
>
> If someone at WSRO records a newscast in Rivendell, I want it to show up
> at WBAS with the same cart number, metadata, and audio; and if someone
> records a spot at WBAS, I want it to show up at WSRO.
>
> Moreover, I also want logs generated at one station to be available at the
> other.
>
> I've been able to make this happen reliably using my Perl scripts, but
> only by reading and writing directly to and from the MySQL CART, CUTS,
> LOGS, and *_LOG tables. I'm looking for an alternative that isn't likely
> to be broken when someone upgrades to a later version of Rivendell that
> might use a different database schema.
>
>
> Rob
>
>
> --
> Я там, где ребята толковые,
> Я там, где плакаты "Вперёд",
> Где песни рабочие новые
> Страна трудовая поёт.
>
> On Mon, 13 Jun 2016, Fred Gleason wrote:
>
> > On Jun 13, 2016, at 14:33, drew Roberts  wrote:
> >   I am not sure about all metadata, but WO puts things like artist
> >   and title in the file. When you import into another system, this
> >   comes along. (IIRC.)
> >
> > This has been true for Rivendell as well for quite some time.
> >
> >   It would likely be good if we had the option to leave the file
> >   name as cart_cut or change it to something like title_artist or
> >   artist_title.
> >
> > The main limitation with the current scheme is the relative paucity of
> > available metadata fields.  For formats that offer transparent audio
> > quality, you’re basically limited to WAV, which means BWF/CartChunk for
> > metadata.  Not much there beyond Title, Artist and Client (although
> there is
> > support for providing Start/End, Segue and Talk marker data, a facility
> > which Rivendell takes full advantage of).  Various automation vendors
> have
> > proprietary extensions that provide more fields, but those are pretty
> much
> > limited to interoperation within that vendor’s product offerings (and
> > Rivendell, which will read a number of those formats).
> >
> > While we could go down the road of inventing Yet Another One-Off Metadata
> > Format, it’d far more useful to use something that is a bit more industry
> > standard while also offering the ability to capture the full range of
> > available fields.  Those may be incompatible requirements.  Any ideas?
> >
> > Cheers!
> >
> >
> > |--|
> > | Frederick F. Gleason, Jr. |  Chief Developer |
> > |   |  Paravel Systems |
> > |--|
> > | Text processing has made it possible to right-justify any idea,  |
> > |even one which cannot be justified on any other grounds.  |
> > |-- J. Finnegan, USC.  |
> > |--|
> >
> >___
> Rivendell-dev mailing list
> Rivendell-dev@lists.rivendellaudio.org
> http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
>
___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Synchronizing carts and logs

[Rob Landry]

I can't speak for anyone else, but I'm not looking to export Rivendell 
cuts, but to have them show up on a Rivendell system attached to a 
different server.


Say, for instance, my client has two radio stations which I will call WSRO 
(Framingham) and WBAS (Hyannis).


If someone at WSRO records a newscast in Rivendell, I want it to show up 
at WBAS with the same cart number, metadata, and audio; and if someone 
records a spot at WBAS, I want it to show up at WSRO.


Moreover, I also want logs generated at one station to be available at the 
other.


I've been able to make this happen reliably using my Perl scripts, but 
only by reading and writing directly to and from the MySQL CART, CUTS, 
LOGS, and *_LOG tables. I'm looking for an alternative that isn't likely 
to be broken when someone upgrades to a later version of Rivendell that 
might use a different database schema.



Rob


--
Я там, где ребята толковые,
Я там, где плакаты "Вперёд",
Где песни рабочие новые
Страна трудовая поёт.

On Mon, 13 Jun 2016, Fred Gleason wrote:


On Jun 13, 2016, at 14:33, drew Roberts  wrote:
  I am not sure about all metadata, but WO puts things like artist
  and title in the file. When you import into another system, this
  comes along. (IIRC.)

This has been true for Rivendell as well for quite some time.

  It would likely be good if we had the option to leave the file
  name as cart_cut or change it to something like title_artist or
  artist_title.

The main limitation with the current scheme is the relative paucity of
available metadata fields.  For formats that offer transparent audio
quality, you’re basically limited to WAV, which means BWF/CartChunk for
metadata.  Not much there beyond Title, Artist and Client (although there is
support for providing Start/End, Segue and Talk marker data, a facility
which Rivendell takes full advantage of).  Various automation vendors have
proprietary extensions that provide more fields, but those are pretty much
limited to interoperation within that vendor’s product offerings (and
Rivendell, which will read a number of those formats).

While we could go down the road of inventing Yet Another One-Off Metadata
Format, it’d far more useful to use something that is a bit more industry
standard while also offering the ability to capture the full range of
available fields.  Those may be incompatible requirements.  Any ideas?

Cheers!


|--|
| Frederick F. Gleason, Jr. |              Chief Developer             |
|                           |              Paravel Systems             |
|--|
|     Text processing has made it possible to right-justify any idea,  |
|            even one which cannot be justified on any other grounds.  |
|                                                -- J. Finnegan, USC.  |
|--|

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Synchronizing carts and logs

[Lorne Tyndale]

Rob,

If you're going from Rivendell to Rivendell, there is always the
rivendell_filter script

http://rivendell.tryphon.org/wiki/RIVENDELL_FILTER.txt_-_Usage_Notes_for_the_'rivendell_filter'_Import_Script.

It'll copy over carts, metadata, etc.




> I had a discussion with a Rivendell user in western New Hampshire this 
> morning -- not one of my clients -- who said he wished Rivendell had the 
> ability to transfer files with metadata seamlessly from one server to 
> another, as (he claims) Wide Orbit and NexGen do.
> 
> I mentioned that I wrote a couple of Perl scripts to do this (actually, 
> one script handles files, while the other handles logs). I use the 
> METADATA_DATETIME field in the CART table and the MODIFIED_DATETIME field 
> in LOGS to determine which copy of a record is more recent, and 
> synchronize accordingly. The only hitch is that it isn't possible to 
> delete a log or cart, since the time stamp for a record is deleted with 
> the record. If we need to delete something, we must delete it manually 
> from both machines simultaneously. While that's not a problem with just 
> two servers, it might be a challenge were we synchronizing a dozen of 
> them.
> 
> What concerns me is upgrading to new versions of Rivendell and the need to 
> go through both scripts to see if any changes have been made to the CART, 
> CUTS, LOGS, or *_LOG tables that might break the scripts.
> 
> If a future database schema omits, say, METADATA_DATETIME, one or both 
> scripts might break irreparably.
> 
> Is there a better way to solve the synchronization problem (say, through 
> the Web interface)?
> 
> Doing a database backup/restore once a day and rsync'ing /var/snd, as some 
> have suggested, is impractical.
> 
> I am curious how other RD users have approached this problem.
> 
> 
> Rob
> 
> -- 
> Я там, где ребята толковые,
> Я там, где плакаты "Вперёд",
> Где песни рабочие новые
> Страна трудовая поёт.___
> Rivendell-dev mailing list
> Rivendell-dev@lists.rivendellaudio.org
> http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Synchronizing carts and logs

[Fred Gleason]

On Jun 13, 2016, at 14:33, drew Roberts  wrote:

> I am not sure about all metadata, but WO puts things like artist and title in 
> the file. When you import into another system, this comes along. (IIRC.)

This has been true for Rivendell as well for quite some time.


> It would likely be good if we had the option to leave the file name as 
> cart_cut or change it to something like title_artist or artist_title.

The main limitation with the current scheme is the relative paucity of 
available metadata fields.  For formats that offer transparent audio quality, 
you’re basically limited to WAV, which means BWF/CartChunk for metadata.  Not 
much there beyond Title, Artist and Client (although there is support for 
providing Start/End, Segue and Talk marker data, a facility which Rivendell 
takes full advantage of).  Various automation vendors have proprietary 
extensions that provide more fields, but those are pretty much limited to 
interoperation within that vendor’s product offerings (and Rivendell, which 
will read a number of those formats).

While we could go down the road of inventing Yet Another One-Off Metadata 
Format, it’d far more useful to use something that is a bit more industry 
standard while also offering the ability to capture the full range of available 
fields.  Those may be incompatible requirements.  Any ideas?

Cheers!


|--|
| Frederick F. Gleason, Jr. |  Chief Developer |
|   |  Paravel Systems |
|--|
| Text processing has made it possible to right-justify any idea,  |
|even one which cannot be justified on any other grounds.  |
|-- J. Finnegan, USC.  |
|--|___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Synchronizing carts and logs

[Wayne Merricks]

I use syncthing to handle the physical file transfers but thats the 
easy bit.  Its a judgement call how you want to update the DB after 
that.  You could set up slave replication in MySQL but then if you slave 
client B to A and you write to B it all breaks.


Obviously CART/CUT info changes all the time (number of plays, last 
played etc), you've also got either the _STACK or _SRT table used in the 
play out reports, potential changes on the sound panels in airplay etc 
etc.


If you could list out what you need replicating between the two, which 
bits should always be the most current version on the master and which 
bits your happy to leave as whatever is the newest time stamp I'm sure 
you could do some MySQL bash/perl scripting magic to get it sorted but 
thats the best I can come up with.


To be honest I kept it simple, I just overwrite the remote clients 
every night with the home server database.  I put in an exception for 
the sound panels, the remote presenters use panels 11 - 20 and home is 1 
- 10.  That way I can do a dump of the panels table and re-insert after 
the mysql import every night.


You do lose any remote files that were imported by drop box stuff 
though.


On 2016-06-13 19:26, Rob Landry wrote:

I had a discussion with a Rivendell user in western New Hampshire
this morning -- not one of my clients -- who said he wished Rivendell
had the ability to transfer files with metadata seamlessly from one
server to another, as (he claims) Wide Orbit and NexGen do.

I mentioned that I wrote a couple of Perl scripts to do this
(actually, one script handles files, while the other handles logs). I
use the METADATA_DATETIME field in the CART table and the
MODIFIED_DATETIME field in LOGS to determine which copy of a record 
is

more recent, and synchronize accordingly. The only hitch is that it
isn't possible to delete a log or cart, since the time stamp for a
record is deleted with the record. If we need to delete something, we
must delete it manually from both machines simultaneously. While
that's not a problem with just two servers, it might be a challenge
were we synchronizing a dozen of them.

What concerns me is upgrading to new versions of Rivendell and the
need to go through both scripts to see if any changes have been made
to the CART, CUTS, LOGS, or *_LOG tables that might break the 
scripts.


If a future database schema omits, say, METADATA_DATETIME, one or
both scripts might break irreparably.

Is there a better way to solve the synchronization problem (say,
through the Web interface)?

Doing a database backup/restore once a day and rsync'ing /var/snd, as
some have suggested, is impractical.

I am curious how other RD users have approached this problem.


Rob


___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Synchronizing carts and logs

[drew Roberts]

Rob,

On Mon, Jun 13, 2016 at 2:26 PM, Rob Landry <41001...@interpring.com> wrote:

> I had a discussion with a Rivendell user in western New Hampshire this
> morning -- not one of my clients -- who said he wished Rivendell had the
> ability to transfer files with metadata seamlessly from one server to
> another, as (he claims) Wide Orbit and NexGen do.
>

I am not sure about all metadata, but WO puts things like artist and title
in the file. When you import into another system, this comes along. (IIRC.)


>
> I mentioned that I wrote a couple of Perl scripts to do this (actually,
> one script handles files, while the other handles logs). I use the
> METADATA_DATETIME field in the CART table and the MODIFIED_DATETIME field
> in LOGS to determine which copy of a record is more recent, and synchronize
> accordingly. The only hitch is that it isn't possible to delete a log or
> cart, since the time stamp for a record is deleted with the record. If we
> need to delete something, we must delete it manually from both machines
> simultaneously. While that's not a problem with just two servers, it might
> be a challenge were we synchronizing a dozen of them.
>
> What concerns me is upgrading to new versions of Rivendell and the need to
> go through both scripts to see if any changes have been made to the CART,
> CUTS, LOGS, or *_LOG tables that might break the scripts.
>
> If a future database schema omits, say, METADATA_DATETIME, one or both
> scripts might break irreparably.
>
> Is there a better way to solve the synchronization problem (say, through
> the Web interface)?
>

My wish is that we could export to wav of flac or wavpack and have the
metadata put into the file from the db on export.

Then on import to another Riv system, that metadata would be stripped from
the file and put into the new system's db.

It would likely be good if we had the option to leave the file name as
cart_cut or change it to something like title_artist or artist_title.


> Doing a database backup/restore once a day and rsync'ing /var/snd, as some
> have suggested, is impractical.
>
> I am curious how other RD users have approached this problem.
>
>
> Rob
>

all the best,

drew
-- 
Bahamain Or Nuttin - http://www.bahamianornuttin.com

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

[RDD] Synchronizing carts and logs

[Rob Landry]

I had a discussion with a Rivendell user in western New Hampshire this 
morning -- not one of my clients -- who said he wished Rivendell had the 
ability to transfer files with metadata seamlessly from one server to 
another, as (he claims) Wide Orbit and NexGen do.


I mentioned that I wrote a couple of Perl scripts to do this (actually, 
one script handles files, while the other handles logs). I use the 
METADATA_DATETIME field in the CART table and the MODIFIED_DATETIME field 
in LOGS to determine which copy of a record is more recent, and 
synchronize accordingly. The only hitch is that it isn't possible to 
delete a log or cart, since the time stamp for a record is deleted with 
the record. If we need to delete something, we must delete it manually 
from both machines simultaneously. While that's not a problem with just 
two servers, it might be a challenge were we synchronizing a dozen of 
them.


What concerns me is upgrading to new versions of Rivendell and the need to 
go through both scripts to see if any changes have been made to the CART, 
CUTS, LOGS, or *_LOG tables that might break the scripts.


If a future database schema omits, say, METADATA_DATETIME, one or both 
scripts might break irreparably.


Is there a better way to solve the synchronization problem (say, through 
the Web interface)?


Doing a database backup/restore once a day and rsync'ing /var/snd, as some 
have suggested, is impractical.


I am curious how other RD users have approached this problem.


Rob

--
Я там, где ребята толковые,
Я там, где плакаты "Вперёд",
Где песни рабочие новые
Страна трудовая поёт.___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev