Question for Deva & Cantar Users

On Wed, 14 Sep 2005 19:02:47 GMT, "Courtney Goodin"
<cmgoodin.TakeThisOut@pacbell.net> schreef:

>I am working on updating the Marker or Cue handling routines in BWF-Widget
>Pro and need to know if the Cantar can drop cues in a BWF file either while
>recording or afterward in Majax. I don't have any sample files with cues or
>markers in them. I looked through the manual and didn't find any reference
>to markers (other than Take types) or Cues.

Not that i know off. I can mark points in the playback, but these are
not written in the actual file AFAIK.
The whole IXML thing is implemented as we speak, and majax will be
updated, but nothing about written markers or cues.

By the way, on the CAS meeting about NL recording, J Coffey tells the
audience that the Deva is able to write tracknames in the metadata (
June-2005 )
I wonder where the Deva leaves that Data in June-2005, since this is
the IXMLpart with the Cantar...This would mean the Deva is putting
this somewhere else, or had already the IXML thing included.....

R ( curious )





--
Http://www.xs4all.nl/~tuig/index.html
 >> Stay informed about: Question for Deva & Cantar Users 

"R°¦-?b?rto¤" <~*y$e-¦@l¤ess.com> wrote in message
news:if4hi1d382d9t1mifhan8hoct03gtq74u3@4ax.com...
> On Wed, 14 Sep 2005 19:02:47 GMT, "Courtney Goodin"
> <cmgoodin.DeleteThis@pacbell.net> schreef:
> By the way, on the CAS meeting about NL recording, J Coffey tells the
> audience that the Deva is able to write tracknames in the metadata (
> June-2005 )
> I wonder where the Deva leaves that Data in June-2005, since this is
> the IXMLpart with the Cantar...This would mean the Deva is putting
> this somewhere else, or had already the IXML thing included.....
>
> R ( curious )
>

The Deva and the SD machines put the Track names in the bext chunk as tags
like "TRK1=Boom Mic"
They have both done this for a while. Simple, human readable and no
perplexing iXML data parsing needed.

----Courtney
 >> Stay informed about: Question for Deva & Cantar Users 

The SD machine doesn´t offer track naming.

frank.
 >> Stay informed about: Question for Deva & Cantar Users 

That´s good. I thought your SD machine could do something mine
couldn´t ;-)

frank.
 >> Stay informed about: Question for Deva & Cantar Users 

The Deva 4/5 and the PD6 both use the same track naming convention in
the BEXT chunk. I think I recall there is a limit of an average of 16
characters per track name if you use all 10 tracks. So once you start
naming a lot of tracks, you start to run into the 256 byte limit of the
BEXT chunk.

I designed the current de-facto standard of storing metadata in BWF
files about 6 years ago for the Deva2 (for use with Avid). I designed
it specifically to be easily readable by both humans and machines. So
all a sound program has to do is display the ASCII description info
as-is for someone to have access to the metadata. This way Cool Edit,
Audition and many other sound programs allow access to this metadata in
a crude way even though the original programmers were not aware of it.

The iXML chunk will just be a more elaborate duplicate of the
information that is stored in the BEXT chunk so this information will
always be available in both forms. The main benefit of iXML is that
there will be no limit imposed on the amount of metadata contained in
each BWF file and each metadata field can have a meaning that is more
strictly defined.

-howy
 >> Stay informed about: Question for Deva & Cantar Users 

On Wed, 14 Sep 2005 22:30:48 GMT, "Courtney Goodin"
<cmgoodin RemoveThis @pacbell.net> schreef:


>They have both done this for a while. Simple, human readable and no
>perplexing iXML data parsing needed.

And about this parsing argument you keep using, does this counts for
the recorder, or does this count for the program, or hardware that
reads the BWF-Data in post ?
In other words, are recorders not able to do this parsing due to a
shortage in present CPU power ?

Roberto





--
Http://www.xs4all.nl/~tuig/index.html
 >> Stay informed about: Question for Deva & Cantar Users 

"wildt®ax" <wildtraxspam.DeleteThis@gmx.de> wrote in message
news:1126776681.927419.21180@g47g2000cwa.googlegroups.com...
The SD machine doesn´t offer track naming.

frank.

Right Frank. I realized it after I hit send. I meant to say the DEVA and
Foxtex 824 (and I believe the DV-40 and PD6).

I have added track names to my SD files using BWF-Widget but you are right
the machine itself does not write or read them.
 >> Stay informed about: Question for Deva & Cantar Users 

"howy" <howard.RemoveThis@zaxcom.com> wrote in message
news:1126804216.798111.160220@g49g2000cwa.googlegroups.com...
> The Deva 4/5 and the PD6 both use the same track naming convention in
> the BEXT chunk. I think I recall there is a limit of an average of 16
> characters per track name if you use all 10 tracks. So once you start
> naming a lot of tracks, you start to run into the 256 byte limit of the
> BEXT chunk.
>
> I designed the current de-facto standard of storing metadata in BWF
> files about 6 years ago for the Deva2 (for use with Avid). I designed
> it specifically to be easily readable by both humans and machines. So
> all a sound program has to do is display the ASCII description info
> as-is for someone to have access to the metadata. This way Cool Edit,
> Audition and many other sound programs allow access to this metadata in
> a crude way even though the original programmers were not aware of it.
>
> The iXML chunk will just be a more elaborate duplicate of the
> information that is stored in the BEXT chunk so this information will
> always be available in both forms. The main benefit of iXML is that
> there will be no limit imposed on the amount of metadata contained in
> each BWF file and each metadata field can have a meaning that is more
> strictly defined.
>
> -howy


Thanks Howy,
Any thought to using the extensible coding history area of the bext chunk or
the "reserved for extension" and currently unused 254 byte area of the chunk
for expansion of Metadata? I don't think the 16 character name limitations
are too onerous. It keeps things simple and easily fits in the limited
display space on the DEVA and on workstation track label areas.

By the way, have you added the "dSPEED=030.000-ND" etc Tag to the DEVA
Metadata so there can be less ambiguity about reading the TC Stamp? This is
the format used by SD and AATON for denoting TC rate in the Bext Chunk. It
would be nice if you incorporated their "defacto standard" so things like
the inDAW system and other software can determine the correct TC rate and
correctly calculate the TC Stamp.

So as I see it, the iXML is just a bloated redundant version of the bext
metadata. And now that the metadata is editable after the fact, simply
doubles (or sometime triples) the work to keep discrepancies from happening
since the data must now be updated in several places in the file if anything
is changed.

---Courtney
 >> Stay informed about: Question for Deva & Cantar Users 

Don´t forget that the infamous AVID supports MXF rather than iXML.
I don´t want to hijack this thread, just want to mention it.

frank.
 >> Stay informed about: Question for Deva & Cantar Users 

Yes. They can co-exist AFAIK. I´d rather have future versions of AVID
dig my meta-data since it´s 99% of the productions I deal with. I
don´t think productions will use FCP instead because of iXML.

frank.
 >> Stay informed about: Question for Deva & Cantar Users 

I even get calls from Editrooms that sound like this:

"Sorry, I have a weird cassette here that was delivered from the
sound-mixer. It´s called DAT or something like that. I have no ideo
how to handle this weird format and I don´t even have a digital sound
card, so could you transfer these tapes to soundfiles?"

I don´t care because I make some money from them but the increasing
lack of even the most basic knowledge especially around the FCP scene
is scary. I get OMFs all the time where the editor simply doubbled or
quadrupled the monoclips on his tracks because he didn´t know he can
control the volume of his monitors with a cheap mixer. "How much is
such a thing" he asked. I said a Behringer starts at 50€. "What?!
That much money for a volume control?" was the reply :-)

ah well...

frank.
 >> Stay informed about: Question for Deva & Cantar Users 

On Fri, 16 Sep 2005 00:26:06 -0700, "Courtney Goodin"
<cgoodin.TakeThisOut@primenet.com> schreef:
>iXML cue markers would not be recognized by most hardware and software as
>there is already a standard defined way of storing CUE markers in the CUE
>chunk of a wave file. This is the method that all the machines that write
>cues are using now. No need for a competing non-standard format to confuse
>the issue.

Well, this is getting a bit strange. I'm not sure what you are
fighting, and why, but basically i get the impression you are against,
since it costs parsing power and HD space, while both of these
arguments seem to be no problem on a HBB, or Cantar, or the new
Fostex.
Is it on the Deva and the SD maybe ?
>
>> Of the two recorders that write iXML, one reads as well as writes and
>> the other just writes it. Bearing in mind, these are acquisition
>> devices, it is not priority to be able to read/playback data recorded
>> on another machine.

This is something that's not clear to me either, but i assume this has
to to with changing data between 2 location recorders..

>Processing issues aside, iXML is mostly redundant data to the required Bext
>and Format chunks in Broadcast Wave file and is therefore a needless and
>confusing complication of metadata interchange

Ehh, if there is a simple program that solves/parses/calculates that,
who cares i would think..
What's your interest in all this ?

>Ok. Here is a REAL example:

Snip

This is what i mean, i do see lot's of more info in the second part
then then i see in the first Bext thing.

>That makes 3 completely redundant places you have to
>change if you have to go back and edit a mistake in the metadata entry after
>the file has been recorded. Otherwise there is a discrepancy that could
>cause confusion.

But do I have to do that, or is this done automatically ? Are we here
in some sort of programmer-war, or is this influencing my daily work
as in it takes me more time ?

>The only thing I Fear about the relentless promotion of a bloated competing
>standard is that if further obfuscates and dilutes the already crowded pool
>of exchange standards making seamless interchange of data less and less
>achievable. (even though they say that is their goal)

The only thing i fear is very simple. If Telecine machines ( Fostex or
Aaton indaw ) support this ixml language, you can already see who's
winning here, as usual.
If your machine does not support it, then you have the problem...

Roberto ( wants all options )





--
Http://www.xs4all.nl/~tuig/index.html
 >> Stay informed about: Question for Deva & Cantar Users 

On 15 Sep 2005 21:24:44 -0700, "Paul Isaacs" <pauli.TakeThisOut@soundtq.co.nz>
schreef:

>
>
>Roberto - you will only benefit from iXML when Cantar supports it in
>its next release, so have no fear.

Well, it's not about fear, or even that i'm pro or contra something is
this matter. I just like to know what's happening with files, what's
the extra stuff, etc, i can never know enough about my machine, and
the files that are used.
I do know that Aaton is starting to use this Ixml, to get more space
on all sides , also ( and most important here ) for the soundreport's
notes that are PDF'd to post.

Now this i do not folow :

>Of the two recorders that write iXML, one reads as well as writes and
>the other just writes it. Bearing in mind, these are acquisition
>devices, it is not priority to be able to read/playback data recorded
>on another machine.

My guess is that you mean there is no need to playback HHB files on a
Cantar , correct ?

The only thing i do think to know is that the AES31 standard that was
announced a few years ago ( 5 ? ) also had this so called easy to read
in mind, but it never made it officially.
Courtney is right if he writes that one is more easy to read on the
eye then the other, but afaik, programs read & write that, not me.
Both CPU power and Memory, or storage arguments are nonsense imo,.(
unless one of the present recorders is not able to do this ) these
might occur when handling and parsing massive amount of files.

From your side of the part, what are the cons of all this IXML ?

R ( there are always cons )






--
Http://www.xs4all.nl/~tuig/index.html
 >> Stay informed about: Question for Deva & Cantar Users