ProppFrexx ONAIR User-Forum

I'm noticing that although I have ARTIST and TITLE columns in my database, any file (tested with WAV) that has native TAGs such as IART, INAM and even BWFOriginator can override these. Is this intentional or a bug?

This is intended by default.
You can change the priority of the TAG evaluation in the general settings, section MetaData. See the tool tips or click on the '?' At the very top right.

I tried the "MetaData has Priority" setting but it does not seem to stop native TAGs from overriding metadata in my database media library.

The former: a media library.

It is still the same, the native TAG data (Title, Artist etc.) always take precedence from the audio file... the '"MetaData has Priority" will only work for .pfp playlist based media libs, as they contain the full information of all meta data.
Else it would be impossible to determine which meta data is comming from which 'source'.

However, the basic idea of ProppFrexx is anyhow to store all meta data inside the audio files standard tags - this to ensure better compatibility and no need to transfer the meta data to other sources, e.g. in case you copy or move the physical audio file.

Mainly I would only use a database for the intial setup/migration and transfer from an older legacy system; and once all data is transferred, a database doesn't bring you any advantages...

The decision to use a database was indeed for ease of migrating from a legacy system, but also because RIFF INFO and BWF did not support all the info we needed.

That said, ID3v2.4 does seem to have the extra fields needed, but considering it is not standard for WAV, does ProppFrexx support that? I know it does for MP3. I've not looked at MP2 yet which some of our much older audio is in (and thankfully being phased out - but won't be completely for a little while yet).

Since we are now getting WAV files from record companies that have metadata from audio editing software (such as "Pro Tools" under BWFOriginator and "Logic Pro X" under IART), it looks like we will have to either migrate, at least partially, or write a tool to strip metadata from WAVs entered into the database.

See the link above regarding meta data.
ProppFrexx supports ALL meta data TAGs also for WAV files (RIFF INFO).
As such there are no limits with the wave format.

How do you use your database? As a 'source' for a media library? Or are you using it as a "MetaData Database"?
If the latter, than yes, the direct audio files TAGs (e.g. the title and artist; see here viewtopic.php?f=9&t=7) always has priority - this is by design and intended.
As such you can quickly change all these TAGs directly and save it to your audio file (incl. wav files).

Alright, I'll have a look.

One more question, out of interest:

radio42 wrote: 13 Jul 2017 15:52 the '"MetaData has Priority" will only work for .pfp playlist based media libs, as they contain the full information of all meta data.
Else it would be impossible to determine which meta data is comming from which 'source'.

Is there a reason why playlist based media libraries are different from database ones? Considering both can contain all metadata, I initially assumed there wasn't too much difference apart from one obviously being a file and one being an SQL server.

ProppFrexx's Meta Data goes beyond plain TAG data, i.e. it includes more complex structures, like lists of event data, lists of cue-points, hot cues, loop points, segues etc.
All this extra meta data can be represented in a nested XML structure quite easily (and thus simply stored to a user TAG field inside the audio file resp. as a sub-structure of the xml based .pfp playlist format), while it typically would require nested structures (e.g. multiple tables) when using a relational database (SQL). Theoretically you could also represent all meta data this in a database, but this is simply not implemented for the database interface ProppFrexx supports - which only supports the main TAG data attributes, but not the other complex meta data structures.
The reason is simple: ProppFrexx was designed with the idea in mind to not leverage a database at all.