On Jul 1, 2013, at 11:54 11, Andy Sayler wrote: > That said, our main reason to want FLAC on the back-end isn't compression, > it's metadata redundancy.
These are actually two unrelated issues. The Broadcast Wave File format currently used in Rivendell is perfectly capable of accommodating metadata. We just don't do it. Why not? Two primary reasons: 1) Performance. Keeping metadata out of the audio data means that Rivendell's caed daemon doesn't have to muck around with talking to MySQL. This not only makes for a big performance win, but also greatly contributes to: 2) Clarity of Design. Trying to keep synchronized copies of the metadata in the WAV data is a notoriously race-prone task. (I've worked with other systems that try (not always successfully) to do it. The results are not pretty.) Doing it properly results in design complications and major code bloat for only marginal benefit. Thus, the decision was made at the very outset of the Rivendell project not even to attempt it. Instead, we let each subsystem do what it does best. BWF handles audio. MySQL handles metadata. I understand your concerns about 'orphaned' audio tracks, but this is yet another reason to maintain a robust backup regime for your Rivendell system. Cheers! |-------------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |-------------------------------------------------------------------------| | Obstacles are what you see when you take your eyes off the road. | | -- Anonymous | |-------------------------------------------------------------------------| _______________________________________________ Rivendell-dev mailing list Rivendell-dev@lists.rivendellaudio.org http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
