Hi, If you run rddbcheck after you change your audio file, it'll go through and fix the cart/cut lengths in the database, based on the actual lengths of the audio tracks (I just did a quick test on a test file / machine I have running an audio file through SOX and speeding it up 5%).
However as you point out this won't fix any segue / talk time / hooks / other markers there. But for me I'm putting it to my backup. Even at only 5%, the Dire Straights track I picked as a test just does not sound right. Another suggestion that I have - when you make a backup of your /var/snd, also grab a backup of your database. > Hi, > > Beware that if you are applying this to an existing library; there are > cart lengths/average_lengths in the CARTS table and I'm pretty sure cut > lengths in the CUT table. > > It would also throw off any segue/talk time/hook/cut start/end markers > you had put in. > > Should be possible to script a 5% increase and adjust markers > accordingly rather than manually changing everything. > > On 2014-11-23 20:50, Lorne Tyndale wrote: > >> I think the answer in this case is clear: pitch alteration belongs > >> in the production room, not the air chain. > > > > I tend to agree with this too. > > > > Another option that I could point out - which essentially would be > > the > > same as doing the alteration in production only without the human > > element involved (thus automating the process for those with large > > libraries). With a few MySQL queries and some scripting it would be > > possible to generate a list of the audio file names in /var/snd for > > which audio pitch speedup is desired. Then - make a backup of > > /var/snd > > (so you'll still have the original) and write a script to use SOX to > > automate the modifying / pitch speed up of any audio tracks you want > > to > > perform that effect on and have that script put the new versions of > > the > > files in /var/snd (make sure they have the same file name as the old > > file name). This should have a similar end-effect of modifying each > > one > > in something like Audacity, without the need to sit there and go into > > each file. > > > > Writing such code should be relatively trivial and potentially > > provide > > the desired result. Since it would not modify any of the Rivendell > > source code it would be unlikely to break anything. And going back > > to > > the original would simply be a matter of restoring the needed files > > from > > backup. > > > > Of course without someone listening to each track (as you would when > > editing each one) you'd lose the human ability to make sure things > > still sound good. > > > > > > _______________________________________________ > > 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
