Re: [RDD] Voice Tracking

[ijames]

I will try That also.

Thanks
Fred

On 2018-10-16 10:40, Fred Gleason wrote:

On Oct 15, 2018, at 20:30, ija...@jamcorbroadcast.com wrote:


Do you have and idea how to delete any voice Tracks that are
imported thru the voice tracker.


Delete the log to which they belong. You can see which log that is by
looking in the ‘OWNER’ column in the cart list in rdlibrary(1).

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] rdimport - audio file location and ingestion

[Sherrod Munday]

On Nov 6, 2018, at 15:42, Fred Gleason  wrote:
> …
> They had an auxiliary program called the ‘SoundHound’ (derisively referred to 
> as the ‘SoundPig’ by one of my co-workers) that would continually scan the 
> set of audio files on the system, building and updating a searchable database 
> of the metadata.

That’s not the only name it was known by… but not all are fit to print. ;-)

I do *not* miss that particular automation system - at all.  As noted, it would 
frequently crash and caused no small amount of consternation and headache.  
With six or seven channels of audio running at our facility, it was ridiculous 
how many times per day we had to go restart that metadata scraper utility on 
multiple machines.

In contrast, dumping the entire mySQL database takes only a few moments 
(completely in the background, even on a running system) and the resulting file 
can be placed anywhere without effort (indeed; it can be written directly to a 
mapped share or RAID system, etc.) so there’s no excuse for not having a backup 
of the database.

--
Sherrod Munday


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

Re: [RDD] rdimport - audio file location and ingestion

[Fred Gleason]

On Nov 6, 2018, at 14:06, Richard Elen  wrote:
> IIRC, you can store a full complement of metadata in a WAV file and there is 
> a standard for it, it's just not commonly done.
> 
There are several public standards for such, as well as a whole slew of _ad 
hoc_ private ones, invented by vendors for use in specific product lines. 


> I must admit that the one thing that has concerned me slightly is the fact 
> that the ingested files are completely unidentifiable - the idea of writing 
> out and maintaining the metadata in the ingested files in case of a need for 
> database reconstruction sounds like a neat idea on the face of it. 
> 
There are some options in Rivendell for aiding the recovery of a damaged audio 
store. See for example the --relink-audio switch in rddbcheck(8).


> On Mon, 5 Nov 2018, Fred Gleason wrote: 
> 
>> ...This was one of the fundamental design principles laid down at 
>> the very inception of the project: the audio store contains *only* audio; 
>> all other metadata goes in the SQL database.
> 
> What was the rationale behind this decision, incidentally? Given the amount 
> of thought that has gone into the project as a whole, I imagine there is a 
> very good reason for it.

At the time (ca. 2002) I was very familiar with a radio automation program 
(name withheld here to protect the guilty) that used this very technique of 
putting the metadata into the audio files. They had an auxiliary program called 
the ‘SoundHound’ (derisively referred to as the ‘SoundPig’ by one of my 
co-workers) that would continually scan the set of audio files on the system, 
building and updating a searchable database of the metadata. For you see, a 
broadcast automation system *needs* a database; it’s the only way you have of 
finding things quickly enough to be useful in a near-realtime system. The 
SoundHound would frequently get behind-hand in keeping the database in sync 
with the metadata that was in the audio files, resulting in all sorts of races, 
crashes and other system mayhem. Also, what’s often forgotten is that metadata 
in a broadcast automation system is an inherently *dynamic* thing; constantly 
being updated and changed. Since the audio files were also the metadata store, 
that meant that they had to rewrite the audio file every time a piece of 
metadata changed: a major non-orthogonality in the system.

Thus, in Rivendell, we make a strong separation: the audio store holds audio 
and the database holds metadata. Audio in the audio store is *immutable*; once 
it’s written, it can never be changed short of being *deleted*. Information in 
the database OTOH can be changed at any time. This separation immediately takes 
an entire class of hard-to-find-and-fix bugs involving the synchronization of 
two non-orthogonal processes off the table while greatly simplifying the 
conceptual model of how the overall system works: a major win in each case. It 
also allows us to use an off-the-shelf RDBMS (MySQL/MariaDB) that has had 
hundreds of thousands of man-hours invested in its design and debugging instead 
of having to whomp up one of our own (a major savings of resources). While this 
does create two sets of data that each require backup, there are 
well-understood techniques in the IT industry for managing such situations.

Cheers!


|--|
| Frederick F. Gleason, Jr. |  Chief Developer |
|   |  Paravel Systems |
|--|
|  It's always good to take an orthogonal view of things.  It  |
|  develops ideas. |
| -- Ken Thompson  |
|--|___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] rdimport - audio file location and ingestion

[Richard Elen]

IIRC, you can store a full complement of metadata in a WAV file and 
there is a standard for it, it's just not commonly done. I must admit 
that the one thing that has concerned me slightly is the fact that the 
ingested files are completely unidentifiable - the idea of writing out 
and maintaining the metadata in the ingested files in case of a need for 
database reconstruction sounds like a neat idea on the face of it.


On Mon, 5 Nov 2018, Fred Gleason wrote:


...This was one of the fundamental design principles laid down at
the very inception of the project: the audio store contains *only* audio;
all other metadata goes in the SQL database. 


What was the rationale behind this decision, incidentally? Given the 
amount of thought that has gone into the project as a whole, I imagine 
there is a very good reason for it.


-_R


On 06-Nov-18 16:50, Rob Landry wrote:


Of course, one consequence of this approach is that if you lose the 
MySQL database, the audio files will be more or less useless.


If each audio file had headers carrying copies of the metadata, it 
would be possible to reconstruct the database fromt hem in the event 
of a disaster. 


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

Re: [RDD] rdimport - audio file location and ingestion

[Fred Gleason]

On Nov 6, 2018, at 11:50, Rob Landry <41001...@interpring.com> wrote:

> Of course, one consequence of this approach is that if you lose the MySQL 
> database, the audio files will be more or less useless.

Yup. Better have a good backup plan in place!


> If each audio file had headers carrying copies of the metadata, it would be 
> possible to reconstruct the database fromt hem in the event of a disaster.

And if you lose the audio files, you’re done also. Ditto on the backup plan.

I don’t see how losing the MySQL DB is perceived as being somehow ‘riskier’ 
than losing the audio data. *Both* are well-understood risks, which can be 
mitigated by a good backup scheme.

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] rdimport - Suggested ingestion parameters?

[Fred Gleason]

On Nov 6, 2018, at 12:15, David Klann  wrote:

> My experience has been that rdimport ignores _all_ of the
> metadata if it finds problems with _any_ of the metadata it (someone
> please correct me if I misunderestimate that).

Can you gives us a specific example of where this occurs?

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] rdimport - audio file location and ingestion

[drew Roberts]

Of course,

if you have the storage space and the horsepower, you could always export
all the audio every so often... This puts a lot of the metadata into the
files exported. Does it put it all? You can export to flac as well...

all the best,

drew

On Tue, Nov 6, 2018 at 11:50 AM Rob Landry <41001...@interpring.com> wrote:

> On Mon, 5 Nov 2018, Fred Gleason wrote:
>
> > They don’t. This was one of the fundamental design principles laid down
> at
> > the very inception of the project: the audio store contains *only* audio;
> > all other metadata goes in the SQL database.
>
> Of course, one consequence of this approach is that if you lose the MySQL
> database, the audio files will be more or less useless.
>
> If each audio file had headers carrying copies of the metadata, it would
> be possible to reconstruct the database fromt hem in the event of a
> disaster.
>
>
> Rob
>
>
> --
> Я там, где ребята толковые,
> Я там, где плакаты "Вперёд",
> Где песни рабочие новые
> Страна трудовая поёт.
> ___
> Rivendell-dev mailing list
> Rivendell-dev@lists.rivendellaudio.org
> http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
>


-- 
Enjoy great *Bahamian Music* at:
Bahamian 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] rdimport - Suggested ingestion parameters?

[David Klann]

Hi Richard,

On 11/5/18 5:29 PM, Richard G Elen wrote:
> Hi...
> 
> I am soon to ingest our music library using rdimport.
> 
> The source library structure is basically
> ~/Artistname/Albumname/trackfiles and they may be multiple album
> subfolders in the Artistname folder.
> 
> We've spent quite a lot of time and effort getting our metadata in good
> order so hopefully all will go well.
> 
> looking at the man pages, rdimport has a great number of options, but,
> being new to this, I wonder if anyone can suggest what is a good
> general-purpose set of configuration options that will be most likely to
> give the best results. Fortunately or unfortunately we have an extremely
> eclectic library ranging from mediaeval to rock, so I am expecting to
> have to do some fine tuning.
> 
> But some basic suggestions would be gratefully received, and thanks in
> advance.

I have written a ZSH script to wrap rdimport. Mostly the script is
irrelevant to your question, but you can see how I invoke it at the
bottom of the attached file (in the series of lines starting with
"${DEBUG} ${RDIMPORT}"). The file is also available on GitHub at
https://github.com/opensourceradio/ram/blob/master/usr/local/bin/import-rd

Given the recent discussion on the list regarding normalization level, I
recommend setting (and will change) the default normalization in the
script from -4 dBFS to -12 dBFS.

While rdimport(1) is pretty good at extracting metadata from audio
files, I like to do so manually, and then set the the database fields to
predictable values on the command line rather than simply leaving them
blank. My experience has been that rdimport ignores _all_ of the
metadata if it finds problems with _any_ of the metadata it (someone
please correct me if I misunderestimate that).

Feel free to ask questions!

  ~David Klann
#!/bin/zsh

setopt NO_CASE_MATCH
zmodload zsh/regex
zmodload zsh/terminfo
autoload colors
colors

# This script complies with Semantic Versioning: http://semver.org/
vMajor=0
vMinor=1
vPatch=4
vHash='$Hash: 917b77e$'

# Tell them how to use this command.
usage() {
  myName=${1}

  ${CAT} << EOF
${myName}: import digital audio tracks into the Rivendell Library using 
rdimport(1).

Summary: ${myName##*/} [ --code (-c) {  or 'list' } ]
   [ --label (-l)  ]
   [ --normalization  ]
   --group (-g) {  or 'list' }
   audio-file ...

You may use the word "list" for the --code (-c) and --group (-g)
options. This will cause ${myName##*/} to list the available codes or
groups and prompt for which one(s) to use. You may specify multiple
Scheduler Codes with the "-c" (aka "--code") option; do this by
specifying the codes separated by commas (you must quote the list of
Scheduler Codes if you include spaces between the codes).

This script will set Scheduler Code to the "genre" meta tag if the
"genre" matches a valid Rivendell Scheduler code. Otherwise the
"genre" meta tag will be ignored.

The script will attempt to extract the label name from the meta
tags. You can explicitely set this with the --label option.

Normalization level defaults to -4 dBFS.

EOF
}

# Check to be sure it is a valid Scheduler Code. Returns true or false
# based on the regex match test.
validSchedCode() {
  local definedCodes=${1} ; shift
  local requestedCode=${1} ; shift

  for schedCode in $(echo ${definedCodes}) ; do
[[ "${requestedCode}" = ${schedCode} ]] && return 0
  done

  return 1
}

# Check to be sure it is a valid GROUP. Returns true or false based on
# the regex match test
validGroup() {
  local definedGroups=${1} ; shift
  local requestedGroup=${1} ; shift

  [[ "${definedGroups}" =~ ".*${requestedGroup}.*" ]]
}

# Figure out the file type and extract the meta tags from it.
tags() {
  local track="${1}"

  # NB: these string match tests are performed case INsensitively
  # (see setopt, above).
  if [[ "${track##*.}" = 'flac' ]] ; then
flacTags "${track}"
  elif [[ "${track##*.}" = 'ogg' ]] ; then
vorbisTags "${track}"
  elif [[ "${track##*.}" = 'mp3' ]] ; then
id3Tags "${track}"
  else
echo "${BOLD}Cannot figure out what kind of file this is. I give 
up!${NORM}" >&2
exit
  fi
}

# We prefer the style of metaflac(1), so leave these alone.
flacTags() {
  local track="${1}"

  ${METAFLAC} --list --block-type=VORBIS_COMMENT "${track}" | ${FGREP} ' 
comment['
}

# We prefer the style of metaflac(1), so do only minimal processing.
# Output from vorbiscomment(1) is expected to be simply "key=value" format.
vorbisTags() {
  local track="${1}"
  local index=1

  ${VORBISCOMMENT} --list "${track}" | while read line ; do

echo "comment[$((index++))]: ${line}"

  done
}

# We prefer the style of metaflac(1), so convert the ID3 tags to
# metaflac style.
id3Tags() {
  local track=${1}

  ${ID3INFO} "${track}" | while read line ; do
case "${line#=== }" in
  TT2*|TIT2*) echo "comment[1]: title=${line#*: }" ;; # 
(Title/songname/content 

Re: [RDD] rdimport - audio file location and ingestion

[Rob Landry]

On Mon, 5 Nov 2018, Fred Gleason wrote:


They don’t. This was one of the fundamental design principles laid down at
the very inception of the project: the audio store contains *only* audio;
all other metadata goes in the SQL database.


Of course, one consequence of this approach is that if you lose the MySQL 
database, the audio files will be more or less useless.


If each audio file had headers carrying copies of the metadata, it would 
be possible to reconstruct the database fromt hem in the event of a 
disaster.



Rob


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

[RDD] Log not fully loaded

[Peter Claes]

Guys,

I have a problem in airplay, which is not consitent.

Sometimes there are some carts missing in the log, usually before a timed event.
This only happens if the system loads the log during a Chainto.

If I manually reload the log, it loads all carts.

Any ideas on this ?

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