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

[Fred Gleason]

On Nov 7, 2018, at 10:03, Rob Landry <41001...@interpring.com> wrote:

> A client of mine used to use AudioVault. I spent lots of hours examining AV 
> .wav files to see how the metadata was stored, and was surprised to discover 
> that each file stored its metadata twice: in an AV10 chunk, and again in a 
> CART chunk; Lord only knows why. I was left to guess which one was supposed 
> to be authoritative.

The CART chunk is publicly documented as an AES standard [AES46-2002-(r2007)] 
and is there to facilitate interoperability with other systems (a Good Thing). 
The AV10 chunk is proprietary to AudioVault, and contains additional ‘secret 
sauce’ (things like outcue strings, post marker location, etc) that are not 
included in the standard CART chunk. (Rivendell BTW will recognize and use 
*both* when importing metadata from an AV system). Other vendors have other 
'secret sauce’ chunks of their own that serve similar purposes, ‘SCOT’ and 
‘ENCO’ being two that come to mind immediately (yes, Rivendell can read those 
too).


> AudioVault struck me as a thinly disguised Pandora's box of chaos and 
> contradictions. There were layers on top of layers, each one seemingly 
> written by people who knew nothing about the others.

Conway’s Law in action. [See https://en.wikipedia.org/wiki/Conway's_law]


> Date and time formats varied from file to file; I found one in which the 
> durations of audio files were stored as floating point numbers representing 
> fractions of a day.

My favorite is in a feature of the VMS operating system, where an operator 
could manually specify a system clock offset at boot time. The units of time 
used was the micro-fortnight. (I leave it as an exercise for the student to 
work out a conversion from seconds).


> And underlying it all, like Satan in the pit of Dante's Inferno, was Windows, 
> an operating system written for secretaries and accountants. AVSAT would 
> crash from time to time during Boston Celtics games when it tried to record 
> news headlines into a file that AVAIR had cued up to play at the next break. 
> The Celtics would call for the break, AVAIR would play it, and then there'd 
> be silence... Rivendell would have handled it all seamlessly.

No further comment necessary.

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

[Rob Landry]

On Tue, 6 Nov 2018, Fred Gleason wrote:


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.


That makes perfect sense.


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.


What I do for several stations is maintain a second Rivendell system at 
the transmitter site. I run a cron job at the studio that periodically 
compares the CART and CUTS tables between the studio and transmitter 
systems; it updates the database at the transmitter with any changes made 
at the studio, and rsync's the corresponding audio files from the stutio 
to the transmitter site.


I have a second cron job running that does the same thing with logs. The 
transmitter site system is therefore up tyo date with the latest songs, 
spots, voice tracks, weather forecasts, etc. and can be put on the air 
with the flick of a relay if anything goes wrong at the studio.


In addition, I have the MySQL database at the studio backup up nightly by 
yet another cron job, and the backups kept for a week before being 
overwritten.



Rob

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

___
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

[Rob Landry]

Well, the other side of the coin is that if you have two copies of the 
metadata, one in a MySQL database and the other in the file headers, then 
you need some mechanism to keep them synchronized. Otherwise you become 
the proverbial man with two watches who can never be sure what time it is.


A client of mine used to use AudioVault. I spent lots of hours examining 
AV .wav files to see how the metadata was stored, and was surprised to 
discover that each file stored its metadata twice: in an AV10 chunk, and 
again in a CART chunk; Lord only knows why. I was left to guess which one 
was supposed to be authoritative.


AudioVault struck me as a thinly disguised Pandora's box of chaos and 
contradictions. There were layers on top of layers, each one seemingly 
written by people who knew nothing about the others. Date and time formats 
varied from file to file; I found one in which the durations of audio 
files were stored as floating point numbers representing fractions of a 
day.


And underlying it all, like Satan in the pit of Dante's Inferno, was 
Windows, an operating system written for secretaries and accountants. 
AVSAT would crash from time to time during Boston Celtics games when it 
tried to record news headlines into a file that AVAIR had cued up to play 
at the next break. The Celtics would call for the break, AVAIR would play 
it, and then there'd be silence... Rivendell would have handled it all 
seamlessly.



Rob

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

On Tue, 6 Nov 2018, 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. 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

[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 - 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 - 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

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

[Fred Gleason]

On Nov 5, 2018, at 17:44, John Edstrom  wrote:

> Interesting.  According to the doc the BWF V2 standard accomodates EBU
> R128 loudness metadata, which someone was asking about the other day. 
> Am I correct in interpreting that to mean than its OK to include
> loudness metadata in the audio file, and it will be stripped and stored
> in the DB, but the playout algorithm, so far, ignores it?

Haven’t really wrapped my head around R128 yet. I plan to do so once v3.x is 
production-ready.

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

[Richard Elen]

Hi, Robert...

It's heading that way. I indeed picked up a used machine for the current 
experiments and it should be fine for the application. Thankfully 
storage is cheap too: I have a 2TB drive on its way. I'll let rdimport 
ingest from the existing NTFS copy of the library and save its version 
on the new drive.


--Richard E


On 05-Nov-18 21:59, Robert Jeffares wrote:


I would heartily recommend you build  a Rivendell system on a 
dedicated computer.


You can source 2nd hand 64 bit machines relatively inexpensively and 
they work quite well.


You may need to install a bigger drive for /var/snd depending on the 
music library size, but you can run with almost anything to see how it 
works.




___
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]

Hi, Fred...

Many thanks for these helpful comments, much appreciated.

--Richard E


On 05-Nov-18 21:39, Fred Gleason wrote:
...the audio store contains *only* audio; all other metadata goes in 
the SQL database.


...The European Broadcasting Union has codified the standard audio 
storage format for use in professional broadcast storage and play-out 
systems. Rivendell (as well as many proprietary systems) adhere to 
these standards


___
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

[John Edstrom]

On Mon, 2018-11-05 at 16:39 -0500, Fred Gleason wrote:
> On Nov 5, 2018, at 16:17, Richard Elen  wrote:
> ...
> 
> It's a matter of standards-compliance. The European Broadcasting
> Union has codified the standard audio storage format for use in
> professional broadcast storage and play-out systems. Rivendell (as
> well as many proprietary systems) adhere to these standards:
> 
>   https://tech.ebu.ch/docs/tech/tech3285.pdf

Interesting.  According to the doc the BWF V2 standard accomodates EBU
R128 loudness metadata, which someone was asking about the other day. 
Am I correct in interpreting that to mean than its OK to include
loudness metadata in the audio file, and it will be stripped and stored
in the DB, but the playout algorithm, so far, ignores it?

   JE


-- 
John Edstrom 
Firebare

___
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

[Robert Jeffares]

Hi Richard,

I would heartily recommend you build  a Rivendell system on a dedicated 
computer.


You can source 2nd hand 64 bit machines relatively inexpensively and 
they work quite well.


You may need to install a bigger drive for /var/snd depending on the 
music library size, but you can run with almost anything to see how it 
works.


Yes all audio is stored as wav for good reason.

Bit of effort but I can assure you it's worth it.

regard

Robert Jeffares



On 06/11/18 05:20, Richard G Elen wrote:


Hi...

I am just starting with Rivendell, so please pardon my total lack of 
knowledge at this point which may result in my asking meaningless or 
impossible questions.


I had set up a CentOS 7.5 system in advance and then followed the 
Rivendell CentOS installation document to install Rivendell (the only 
difference from the document's recommendation being that I did not 
define a separate partition for /var, as I followed the standard 
CentOS install recommendation).


As I want to get to know Rivendell for a while and continue to use an 
existing Windows playout system in the meantime, the machine 
dual-boots into CentOS or Win 10. A 1.5 TB partition on the drive is 
formatted as NTFS and contains the music library, which is accessed by 
the Windows playout system currently. The library is mounted with 
ntfs-3g on boot into CentOS so it can be accessed by Rivendell.


It appears that Rivendell requires to make a complete copy of the 
music library on ingestion with rdimport. This is inconvenient. There 
is insufficient space on the current drive to allow Rivendell to store 
a copy of the music library. Now of course I could attach an external 
drive, copy the library on to it and then let Rivendell ingest it from 
there and copy it back to where it is now. In which case, two 
questions arise:


 1. If I follow the copy-back-and-forth course outlined above, will
the Rivendell-ingested copy of the music library still be able to
be used by the Windows playout system or would I need to have /two
/active copies of the music library, one for Windows playout and
the other for Rivendell?
 2. Does Rivendell require to make a copy of the library at all, or
can it simply ingest the metadata and populate the database
without copying the actual audio files?

Any observations or advice would be greatly appreciated, and thanks in 
advance.


--Richard Elen
radioriel.org



___
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

[Fred Gleason]

On Nov 5, 2018, at 16:17, Richard Elen  wrote:

> While the Windows system could no doubt play the WAV files produced by 
> Rivendell, they may not contain any metadata, so it wouldn't know what they 
> were.

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.


> I wouldn't dream of using a lossy compression scheme on the library. I just 
> find it interesting that RD would turn an mp3 file into a WAV file (or a FLAC 
> file into a WAV file for that matter), neither of which confer any sonic 
> benefit.

It's a matter of standards-compliance. The European Broadcasting Union has 
codified the standard audio storage format for use in professional broadcast 
storage and play-out systems. Rivendell (as well as many proprietary systems) 
adhere to these standards:

https://tech.ebu.ch/docs/tech/tech3285.pdf

So, while it’s common short-hand in many shops to use ‘WAV’ to mean 
‘uncompressed PCM’, WAV is actually just a container format (specifically, a 
Microsoft RIFF format, similar to AVI and similar formats) that can enclose 
many different audio encodings.

Cheers!


|--|
| Frederick F. Gleason, Jr. |  Chief Developer |
|   |  Paravel Systems |
|--|
|  There is nothing unexplainable, only that which has yet to  |
|  be explained."  |
| --Dr. Who|
|--|

___
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]

Observations based on your comments - for which thank you again!

On 05-Nov-18 20:58, drew Roberts wrote:

What does the windows system do with the audio that it cannot work 
with the Riv files?


The Windows playout system reads the metadata from the audio files and 
stores it in a database that points at the original files. While you can 
have it make a copy of the library on ingestion it doesn't have to. So 
the original files are played out, from their original formats.


While the Windows system could no doubt /play/ the WAV files produced by 
Rivendell, they may not contain any metadata, so it wouldn't know what 
they were. I know that WAV /can /contain metadata but very few 
applications do that. Does RD keep metadata in the WAV file or simply 
store it in the database? If you are going to all that trouble the 
latter would seem to be the way to go.



...If you use that, you use the compressed format you will:

1. lose quality wrt your flac files.
2. incur re-encoding losses from your mp3s.


I wouldn't dream of using a lossy compression scheme on the library. I 
just find it interesting that RD would turn an mp3 file into a WAV file 
(or a FLAC file into a WAV file for that matter), neither of which 
confer any sonic benefit. Presumably what this /does /do is to ensure 
that the system only ever has to play out WAV files and that files 
ingested will never be stored at /lower/ quality than they come in.


If you have room in the box, it is likely more than worth it to put in 
a drive for /var/snd..


It's not difficult OS-wise to add another drive and move /var on to it, 
so that's what I'm looking at. I can pull the DVD drive (I have an 
external USB one somewhere) and put a drive in there instead.


Many thanks once again,
--Richard E

___
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]

Richard,

glad to know the info was useful. A few clarifications...

On Mon, Nov 5, 2018 at 3:01 PM Richard Elen  wrote:

> Hi, Drew...
>
> This is exceptionally useful information, and thank you.
>
> OK, so the current setup won't work. Not only that, my entire
> installation won't work - if the library needs to be stored in /var/snd/
> then it DOES require its own partition - indeed, its own drive.
>

Technically now always but in fact, usually a very good idea.

>
> In addition, if I want to run both a Windows system and Rivendell on the
> same machine as dual-boot I will indeed need two libraries, one in
> native format (mainly FLAC plus some mp3s) under NTFS and one generated
> by Rivendell under xfs, probably on its own drive mounted at /var.
>

What does the windows system do with the audio that it cannot work with the
Riv files?

>
> You note that Rivendell will convert all files to .WAV (even if they are
> lossy compressed, interestingly) so I need to allow a seriously larger
> space for the library.
>
> PCM16, PCM24, MPEG Layer 2

are options you set in rdadmin for the rdlibrary setting of a host.

IIRC, even the MPEG Layer 2 files show up with a .wav extension.

If you use that, you use the compressed format you will:

1. lose quality wrt your flac files.
2. incur re-encoding losses from your mp3s.


> I'm very glad I learned this now when I'll only have wasted a day or so
> building the system, and not some way further down the line, so I am
> very grateful for the comments.
>

If you have room it the box, it is likely more than worth it to put in a
drive for /var/snd...

>
> Many thanks!
> --Richard E
>
> all the best,

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

[Richard Elen]

Hi, Drew...

This is exceptionally useful information, and thank you.

OK, so the current setup won't work. Not only that, my entire 
installation won't work - if the library needs to be stored in /var/snd/ 
then it DOES require its own partition - indeed, its own drive.


In addition, if I want to run both a Windows system and Rivendell on the 
same machine as dual-boot I will indeed need two libraries, one in 
native format (mainly FLAC plus some mp3s) under NTFS and one generated 
by Rivendell under xfs, probably on its own drive mounted at /var.


You note that Rivendell will convert all files to .WAV (even if they are 
lossy compressed, interestingly) so I need to allow a seriously larger 
space for the library.


I'm very glad I learned this now when I'll only have wasted a day or so 
building the system, and not some way further down the line, so I am 
very grateful for the comments.


Many thanks!
--Richard E

___
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]

Richard,
On Mon, Nov 5, 2018 at 11:20 AM Richard G Elen  wrote:

> Hi...
>
> I am just starting with Rivendell, so please pardon my total lack of
> knowledge at this point which may result in my asking meaningless or
> impossible questions.
>

We all start somewhere. Welcome.


> I had set up a CentOS 7.5 system in advance and then followed the
> Rivendell CentOS installation document to install Rivendell (the only
> difference from the document's recommendation being that I did not define a
> separate partition for /var, as I followed the standard CentOS install
> recommendation).
>
> As I want to get to know Rivendell for a while and continue to use an
> existing Windows playout system in the meantime, the machine dual-boots
> into CentOS or Win 10. A 1.5 TB partition on the drive is formatted as NTFS
>

I don't think Rivendell is going to like that formatting... IIUC, it is
going to want a filesystem that can handle unix/linux idioms.


> and contains the music library, which is accessed by the Windows playout
> system currently. The library is mounted with ntfs-3g on boot into CentOS
> so it can be accessed by Rivendell.
>
> It appears that Rivendell requires to make a complete copy of the music
> library on ingestion with rdimport. This is inconvenient.
>

Perhaps, but it is what it is.


> There is insufficient space on the current drive to allow Rivendell to
> store a copy of the music library. Now of course I could attach an external
> drive, copy the library on to it and then let Rivendell ingest it from
> there and copy it back to where it is now. In which case, two questions
> arise:
>
>1. If I follow the copy-back-and-forth course outlined above, will the
>Rivendell-ingested copy of the music library still be able to be used by
>the Windows playout system or would I need to have *two *active copies
>of the music library, one for Windows playout and the other for Rivendell?
>
>
So, that may be very dangerous. If the windows playout system can deal with
wav files in a read only way, if it does not try to make any changes to
those wav files, it may work for a while.


>
>1. Does Rivendell require to make a copy of the library at all, or can
>it simply ingest the metadata and populate the database without copying the
>actual audio files?
>
>
When Rivendell ingests audio, if you are doing what is recommended, it will
put everything (make a copy) in /var/snd as .wav files.
Like so:

55_236.wav
550001_123.wav
99_001.wav

6digitcartnum_3digitcutnum.wav

Is the windows system going to be able to deal with such files. Does
windows have the ability to work with linux partitions these days?
(xfs/ext4/ext3?)

>
>1.
>
> Any observations or advice would be greatly appreciated, and thanks in
> advance.
>
> --Richard Elen
> radioriel.org
>
> all the best,

drew
-- 
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