I've been using Pro Tools for almost two decades now and I just had a rather rude awakening. I frequently need to create conformed WAV files that are in the SMPTE/ITU channel order of L/R/C/LFE/Ls/Rs/LFE. However Pro Tools, ever since it allowed creating multichannel interleaved files, has always rigidly trapped you into L/C/R/Ls/Rs/LFE without any user-selectable options for changing this. In the past, I've worked around this issue by cheating and vertically organizing the tracks in the order I need and then outputting to an interleaved file. That worked, but it's a bit of a kluge. These days, I generally keep the files as separate-mono and then use SoundGrinder Pro to create interleaved files in whichever order the client requests.
Unfortunately, one of our clients has been having trouble with my workflow. I've been told that the file we delivered to them has been giving them problems. They are trying to use the file in a Dolby DP600 Optimizer. I've never had any experience with one of those units nor do I have access to one for testing purposes. I'm told that the DP600 alters the file in such a way rendering it unplayable. They have also told us that this problem only happens with files I've created in Sound Grinder Pro. Files they received from other vendors are fine.
After reaching out to one of the more technical minded engineers at our client's facility, I've learned that the problem has to do with the order of the chunks that make up the file. Chunks are basically all the elemental units that are inside all RIFF/WAV files. All chunks have the same basic components. A four-character identifier, an integer number that represents its byte-size, and the actual binary data. Things like sample rate, bit-depth, and number of channels exist in the 'fmt ' chunk. Additional broadcast WAV metadata can be found in the 'bext' chunk. All of the sound data lives in the 'data' chunk. Most applications define additional proprietary chunks of their own that other applications simply ignore. Using a hex-editor, you can examine these chunks, and even alter them if you're daring. Most chunks are sized so they contain even numbers of bytes. This keeps all the chunk-offsets word-aligned inside the file for optimization purposes. Sometimes, chunks will contain an odd number of bytes. In that case, a zero-byte will be added as a pad so the following chunk is word-aligned.
For whatever reason, Dolby feels that it's necessary to restructure files and change the order of these chunks. In the process, it moves all of the chunks at the end of the file to the start and makes the 'data' chunk the final chunk. I'm also told that the problem seems to stem from the presence of an odd-sized chunk in the file. It would seem that the file parser in the DP600 is not smart enough to account for the extra pad-byte that follows an odd-sized chunk.
Well, now that I've covered all the background for my problem, here is the meat of it. Our client wants us to create an interleaved using Pro Tools to see if it will be compatible to the DP600. So, I organized my channels vertically to the order I need to output to my WAV file as L/R/C/LFE/Ls/Rs. I named the individual files as L/C/R/Ls/Rs/LFE. I selected the file-set in the clip-list and exported my interleaved file. As a sanity check, I imported the interleaved file to make sure it imports in the correct order vertically. Everything looked good so we delivered the file.
About two weeks later, I learned that the file was rejected for being in the wrong order. I checked the file again in Pro Tools, and just like before, it appeared to be correct. I e-mailed my supervisor saying the file is correct on my workstation.
My past correspondences with this client has shown me that he has a good technical understanding of these formats and he does know what he is doing, unlike some of the other people I've dealt with so there must be something I'm missing. I opened the new interleaved file in Sound Grinder Pro. In the "Channels" column, instead of displaying "6-channel", it shows "5.1". My heart suddenly sank. I went to the waveform display in Sound Grinder Pro and saw that they were not in the order I expected. The center channel was clearly channel 2 just as our client insists. Time to grab a towel to wipe the egg off my face.
It would appear that the file writer in Pro Tools has changed it's behavior. Six-channel interleaved files are now written as Extensible Broadcast WAV files with a channel-mask in the order of L/R/C/LFE/Ls/Rs. That also means that Pro Tools now reorders channels from what is displayed in the session. Since I did my own manual reordering, that was erroneously done twice ultimately producing a file that is interleaved in the order of L/C/R/Rs/LFE/Ls! When I import the interleaved file into Pro Tools as a sanity check to examine the order, Pro Tools interprets the channel-mask reorganizing the channels so they appear correct leaving me blissfully unaware of this problem! Thank you, Avid, for making me appear like an idiot to my clients with egg on my face!
Unfortunately, one of our clients has been having trouble with my workflow. I've been told that the file we delivered to them has been giving them problems. They are trying to use the file in a Dolby DP600 Optimizer. I've never had any experience with one of those units nor do I have access to one for testing purposes. I'm told that the DP600 alters the file in such a way rendering it unplayable. They have also told us that this problem only happens with files I've created in Sound Grinder Pro. Files they received from other vendors are fine.
After reaching out to one of the more technical minded engineers at our client's facility, I've learned that the problem has to do with the order of the chunks that make up the file. Chunks are basically all the elemental units that are inside all RIFF/WAV files. All chunks have the same basic components. A four-character identifier, an integer number that represents its byte-size, and the actual binary data. Things like sample rate, bit-depth, and number of channels exist in the 'fmt ' chunk. Additional broadcast WAV metadata can be found in the 'bext' chunk. All of the sound data lives in the 'data' chunk. Most applications define additional proprietary chunks of their own that other applications simply ignore. Using a hex-editor, you can examine these chunks, and even alter them if you're daring. Most chunks are sized so they contain even numbers of bytes. This keeps all the chunk-offsets word-aligned inside the file for optimization purposes. Sometimes, chunks will contain an odd number of bytes. In that case, a zero-byte will be added as a pad so the following chunk is word-aligned.
For whatever reason, Dolby feels that it's necessary to restructure files and change the order of these chunks. In the process, it moves all of the chunks at the end of the file to the start and makes the 'data' chunk the final chunk. I'm also told that the problem seems to stem from the presence of an odd-sized chunk in the file. It would seem that the file parser in the DP600 is not smart enough to account for the extra pad-byte that follows an odd-sized chunk.
Well, now that I've covered all the background for my problem, here is the meat of it. Our client wants us to create an interleaved using Pro Tools to see if it will be compatible to the DP600. So, I organized my channels vertically to the order I need to output to my WAV file as L/R/C/LFE/Ls/Rs. I named the individual files as L/C/R/Ls/Rs/LFE. I selected the file-set in the clip-list and exported my interleaved file. As a sanity check, I imported the interleaved file to make sure it imports in the correct order vertically. Everything looked good so we delivered the file.
About two weeks later, I learned that the file was rejected for being in the wrong order. I checked the file again in Pro Tools, and just like before, it appeared to be correct. I e-mailed my supervisor saying the file is correct on my workstation.
My past correspondences with this client has shown me that he has a good technical understanding of these formats and he does know what he is doing, unlike some of the other people I've dealt with so there must be something I'm missing. I opened the new interleaved file in Sound Grinder Pro. In the "Channels" column, instead of displaying "6-channel", it shows "5.1". My heart suddenly sank. I went to the waveform display in Sound Grinder Pro and saw that they were not in the order I expected. The center channel was clearly channel 2 just as our client insists. Time to grab a towel to wipe the egg off my face.
It would appear that the file writer in Pro Tools has changed it's behavior. Six-channel interleaved files are now written as Extensible Broadcast WAV files with a channel-mask in the order of L/R/C/LFE/Ls/Rs. That also means that Pro Tools now reorders channels from what is displayed in the session. Since I did my own manual reordering, that was erroneously done twice ultimately producing a file that is interleaved in the order of L/C/R/Rs/LFE/Ls! When I import the interleaved file into Pro Tools as a sanity check to examine the order, Pro Tools interprets the channel-mask reorganizing the channels so they appear correct leaving me blissfully unaware of this problem! Thank you, Avid, for making me appear like an idiot to my clients with egg on my face!
Aucun commentaire:
Enregistrer un commentaire