Jump to content

John Lundsten

Members
  • Posts

    8
  • Joined

  • Last visited

About John Lundsten

  • Birthday 01/01/1

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Phil, reckon you are spot on here. AES31-3 was (rather like MIDI had been a while previously) a brilliant initiative to harness the collective talent of those with knowledge & ability, audio engineers, academics, including those motivated to sell 'kit', "make a better mousetrap". MIDI had an everybody won result. AES31-3 was killed / screwed by, I can't help thinking those who feared a very well thought out way to interchange Project/Session data would compromise their stupendously inferior (er, no doubt shit) attempts. John L - AATranslator - London
  2. IMO PT10, is a viable, actually rather good DAW, or also IMO version 9 < are a pretty bad joke. The limited timeline being one of many stupid limitations PT had compared to any other DAW, yes PT has at long last been updated to 1990's norms. John L
  3. Been meaning to search my test results for this info. A quick look suggests SD may well be way ahead of other file based location recorders in the T/c maximum compatibility front. SD have cleverly designed their recorders to have a file start point (in samples since midnight) at a 00 frame edge. This has a number of advantages as the fcp rate becomes irrelevant, hh mm ss are common regardless of frame rate. For most conversions from fps 'a' to 'b' there won't be an integer, (whole number) number of frames equivalent. So an approximate 'rounded' number will have to be used. Many DAW's /NLE's don't read/know fps info anyway. Or for example FCP which does read & log BWF fps info and when editing behaves as if edits /cuts are 'quantized' {snapped} to the bwf frame rate -- but NO, in fact the Project / sequence frame rate is used. Also 29.97d & 23.976fps does not have an integer number of samples/frame - so a rounded approximation is the only option. The fact is 'X' HH MM SS with no FF is a very good idea to get round all the above issues. It's often impossible to define a 'frame edge' in 'samples' -- 00 frames is a universally available exception.
  4. Interesting observations, I've come across these problem trying to develop a 'Conform' application. It can be a pain how DAW's by their nature & audio files in general work to 'sample' (quantizing) intervals, NLE's to frames (24th till 30th of a sec intervals). Clearly SD have sussed (I use a 788T) that to be compatible to NLE's that at many levels are routed/stuck in the 1980's it's a good idea to start a file at a zero frame, frame edge. IE hh mm ss & zero frame position. Now Sony Vegas (which for reason I don't quite get, is not taken seriously) can have audio to it's natural sample accuracy in combination to video at it's 'frame intervals', Apple FCP can (sort of) too, Avid MC no-way. Why? How does Avid get away with this? John L (AATranslator, London)
  5. Jürg, Thanx for this informed info. At the moment I'm working on developing a 'conform' application that initially will use FCP-xml rather than the 'past their sell by date' CMX 3600 edl's others use. Yes i'm doing loads of tests using the FCP-xml output from FCP7, also from Vegas, Adobe CS, Logic, Pyramix etc. But real World user info is so valued. John L, AATranslator - London
  6. We, well particularly me, at AATranslator have on our 'to do' list a good way to accommodate changes to an edit that audio post folk have already done a significant amount of work on. Now from what i know, seems to me there are a few software tools already available that address the idea of converting picture edit changes (eg via Avid ALE or FCP-xml change lists) & great - can produce info for neg-cutters, do all kinds of neat stuff re 'Keycodes', 3 or 4perf 35mm film etc etc. But Audio as is common in Film/TV post being ignored or with pathetic support. AAT is principally audio orientated, we do video but as an addition to audio (sound with pictures). I would really appreciate some feedback from those principally concerned with good audio as to what you want. What we have in mind is:--- a) Analyse any difference between a previously done AAT conv to any of the dest formats we can do & a new revised conversion to the same destination format. move prev content & add new content to match changes. John L
  7. Well yes AAT is a Windows program, but we have quite a few users who run it quite successfully on Mac's using WINE for OSX, Parallels or VMWare, etc & running AAT on a PC & linking via a LAN works well too. I do a lot of the beta testing & use PC & Mac computers connected via a LAN. We are very aware many media professionals love Mac's, (for some it's their religion) so we can read & write Mac-centric files. Eg handle old (pre OSX) formats like PT5 & media in SD2 format that used the concept of Data & Resource forks central to the way Mac's worked, pre OSX. And cope with files without a file ext, that is important to PC's. Me I'm a bit more familiar with PC's so find Mac OS nice at times but often hard work. But I'm an OS Agnostic at heart & don't understand OS bigotry, they're both just computer OS's. BTW the reason we support pro Tools pt5 (with separate PC & Mac vers) is because it offers Way more 'detail' than OMF or AAF can do. Now we can also convert to PTF which unlike pt5 is cross platform compatible IE it's the same file for either PC's or Macs. John L, AATranslator London
  8. Seams a sensible move. It makes sense of the XML bug fix I got sent yesterday, I thought Apple were just being nice to old customers of FCP.
×
×
  • Create New...