Fwd: Pro Tools 10 - Audio Import @ 96kHz

[James Finnerty]

Begin forwarded message:

From: James Finnerty <finner...@gmail.com>

Date: November 29, 2011 5:51:47 PM EST

To: EaSt <electroa...@concordia.ca>, cec-con...@concordia.ca

Subject: Pro Tools 10 - Audio Import @ 96kHz

Hi lists,

I'm coming across a problem that I have not experienced before in Pro Tools.

I've batch upsampled several audio files from 48kHz to 96 kHz using Izotope RX. Next I created a session in Pro Tools at 96kHz and imported those files so they could be processed.

When the file appears in the edit window it looks like the waveform graphic has been compressed to half the size of the original.

When I playback, the audio does not follow the waveform - for instance, if I set the playhead to a spot past the half-way mark and press play, I can still hear the audio from the original file, even though there is just a flat line (see graphic attached).



I can not make any fades or volume automation on the waveform - they end up not corresponding with the graphic representation.

I recently upgraded to PT10, so I feel like it is either a problem with the new version, a physical RAM issue or an issue with sample rate conversion...

Any suggestions?

Thanks,
James

[peiman khosravi]

It could be the file headers having the wrong info. This could have been caused by RX not rewriting the headers properly. Have you tried opening the files in a sample editor?

Richard Dobson has a great little command-line utility for fixing issues like that in CDP Multi-Channel Toolkit (http://people.bath.ac.uk/masrwd/) called COPYSFX. This lets you make fresh copies of the files, hopefully with the correct headers.  

Best,

Peiman  

--
You received this message because you are subscribed to the "CEC-Conference" group.
To post: cec-con...@googlegroups.com
To unsubscribe: cec-conferenc...@googlegroups.com
More options: https://groups.google.com/forum/#!forum/cec-conference
CEC website: http://cec.sonus.ca

[Jörn Nettingsmeier]

On 11/29/2011 11:55 PM, James Finnerty wrote:
> I'm coming across a problem that I have not experienced before in Pro
> Tools.
>
> I've batch upsampled several audio files from 48kHz to 96 kHz using
> Izotope RX. Next I created a session in Pro Tools at 96kHz and imported
> those files so they could be processed.
>
> When the file appears in the edit window it looks like the waveform
> graphic has been compressed to half the size of the original.

something like this could happen if the peakfiles were created at 48k
for some reason. did you start with a fresh session? could it be that
protools is somehow using old peakfile from before the upsampling process?

--
J�rn Nettingsmeier
Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487

Meister f�r Veranstaltungstechnik (B�hne/Studio)
Tonmeister (VDT)

http://stackingdwarves.net

[James Finnerty]

Thanks Peiman, 

I opened up the files in Amadeus Pro. The audio and graphic lined up perfectly. So I'm not sure it is the file that is the problem...

Just to make sure I understand what you mean by 'sample editor' - would Amadeus fit this description? 

Thanks for the links - I'll try using the COPYSFX utility and see if that fixes the problem. 

Best,

James

On 2011-11-29, at 6:10 PM, peiman khosravi wrote:

It could be the file headers having the wrong info. This could have been caused by RX not rewriting the headers properly. Have you tried opening the files in a sample editor?

Richard Dobson has a great little command-line utility for fixing issues like that in CDP Multi-Channel Toolkit (http://people.bath.ac.uk/masrwd/) called COPYSFX. This lets you make fresh copies of the files, hopefully with the correct headers.  

Best,

Peiman  

On 29 November 2011 22:55, James Finnerty <finner...@gmail.com> wrote:

Begin forwarded message:

From: James Finnerty <finner...@gmail.com>

Date: November 29, 2011 5:51:47 PM EST

To: EaSt <electroa...@concordia.ca>, cec-con...@concordia.ca

Subject: Pro Tools 10 - Audio Import @ 96kHz

Hi lists,

I'm coming across a problem that I have not experienced before in Pro Tools.

I've batch upsampled several audio files from 48kHz to 96 kHz using Izotope RX. Next I created a session in Pro Tools at 96kHz and imported those files so they could be processed.

When the file appears in the edit window it looks like the waveform graphic has been compressed to half the size of the original.

When I playback, the audio does not follow the waveform - for instance, if I set the playhead to a spot past the half-way mark and press play, I can still hear the audio from the original file, even though there is just a flat line (see graphic attached).

<PT_Wave_96kHz.jpg>

I can not make any fades or volume automation on the waveform - they end up not corresponding with the graphic representation.

I recently upgraded to PT10, so I feel like it is either a problem with the new version, a physical RAM issue or an issue with sample rate conversion...

Any suggestions?

Thanks,
James

--
You received this message because you are subscribed to the "CEC-Conference" group.
To post: cec-con...@googlegroups.com
To unsubscribe: cec-conferenc...@googlegroups.com
More options: https://groups.google.com/forum/#!forum/cec-conference
CEC website: http://cec.sonus.ca

[James Finnerty]

Thanks John,

Here are the results of a few tests:

I opened the 96kHz audio files in Amadeus and the waveform is in tact. The audio plays back in correspondence with the graphic representation of the waveform. So the problem is not with the actual files themselves.

Next, I opened a new PT session in 96kHz, imported one of the original 48kHz files and upsampled using Pro Tools SRC. The audio and the waveform remain in tact (a small victory).

Then I opened a 44.1/ 16 bit white noise sample in Izotope and converted the file to 96/24. When importing the upsampled version from Izotope, I received an error message - "White_Noise_96 must be converted ... because it is not BWAVE/AES31 compatible..." After converting, the waveform and audio played back in sync.

Importing the original white noise file (44.1/16) using PT SRC to 96kHz was also fine.

I tried SRC on one singe file from my original sessions (since I initially used batch conversion) and then imported the 96kHz file to PT. The original problem returned.

So, I think it is an RX & PT compatibility issue like you mentioned. Although, my curiosity is peaked regarding WHY this would happen. How is it that the graphic representation of the audio is modified while the audio plays back as it should? Is this a coding deficiency in Pro Tools (as it analyzes the audio during import)? I'm also curious as to why it halves the audio waveform!? This makes me think the problem lies in the SRC settings in Izotope (filter-steepness, cut-off shift and pre-ringing). Does this have anything to do with nyquist frequency or anti-aliasing and the way that Pro Tools handles this information?

Thanks,
James

On 2011-11-29, at 6:19 PM, John Klepko wrote:

could RX fault...there has been compatibility issues keeping up with PT version changes, like I had to dumbdown my v9 a step to have RX2 work properly (in audiosuite mode)
try a short sample simply using using PT10 to upsample (as you import)...to see if PT has an issue with resampling...
also out of interest, try this both ways with a short sample of white noise to examine the difference in waveform level.

[peiman khosravi]

Hello,

Yes I meant something like Amadeus.

Best,

P

[peiman khosravi]

From your descriptions it sounds like a header issue cause by RX. Try
opening the file in Amadeus and exporting it as a new file to try and
overwrite the header. Otherwise copysfx should do this for you.

P

[peiman khosravi]

This is my guess.

Converting a file from 48k to 96k doubles the number of samples in the
file. Now if this increase in samples is somehow not updated in the
header (although I'm no expert at this) then the file will be read as
being half the actual length. Or something along these lines.

There is a utility in Wave Editor for checking audio files for errors
and header inconsistencies. You could try the demo version for free.
http://www.audiofile-engineering.com/waveeditor/ Go to the main Wave
Editor menu and then Audio File First Aid.

P

[James Finnerty]

I tried all of the recommendations below, making three new copies of the same file. Here's what came up...

The file that was converted in RX and imported directly to Pro Tools displayed the same problem - waveform graphic half the size of the file, but audio still in tact.

I saved a copy of the converted file in Amadeus Pro to a new file (same sample rate - just a new name). When importing this file to PT it didn't cause the same problem as the original file.

I also used the COPYSFX command line utility in the CDP Toolkit - but the file turned out the same as the RX original... however, I'm not 100% sure that I was using the command line properly in Terminal.

Here's a copy of the Terminal command and output:

///////

dyn-161-061:~ James$ copysfx /Users/James/Desktop/Ballad_FINAL_2_DENOISE_96\ 2.wav

CDP MCTOOLS: COPYSFX v2.0 (c) RWD,CDP 2009
copy/convert soundfiles
usage: copysfx [-d][-h][-sN] [-tN] infile outfile
-d : apply TPDF dither to 16bit outfile.
-s : force output sample type to type N.
Available sample types:
1 : 16bit integers (shorts)
2 : 32bit integer (longs)
3 : 32bit floating-point
4 : 24bit integer 'packed'
Default: format of infile.
-h : write mimimum header (no extra data).
Default: include PEAK data.
-tN : write outfile format as type N
Possible formats:
0 : standard soundfile (.wav, .aif, .afc, .aifc)
1 : generic WAVE_EX (no speaker assignments)
2 : WAVE_EX mono/stereo/quad(LF,RF,LR,RR) - infile nchans must match
3 : WAVE_EX quad surround (L,C,R,S) - infile must be quad
4 : WAVE_EX 5.1 format surround - infile must be 6-channel
5 : WAVE_EX Ambisonic B-format (W,X,Y,Z...) - file extension .amb supported
6 : WAVE_EX 5.0 Surround - infile must be 5-channel
7 : WAVE_EX 7.1 Surround - infile must be 8-channel
8 : WAVE_EX Cube Surround - infile must be 8-channel
default in all cases: outfile has format of infile
NB: types 1 to 8 are for WAV format only
See also CHXFORMAT: destructively change WAVE_EX GUID and/or speaker mask.
dyn-161-061:~ James$

///////

I was a little confused about the 'infile' and 'outfile' settings - as well as which parameters to choose from (ie. i tired a few times beforehand using -s4 -t0, and setting the infile to the same directory/filename as the outfile... but it created an error message).

If you wouldn't mind suggesting the best way to use the COPYSFX command, I would be willing to try copying the file and testing it in Pro Tools once again.

Thanks!
James

ps. I also use the Audio File First Aid function in Wave Editor and it said that the audio file appeared to be ok.

[peiman khosravi]

Hello,

You need to provide two arguments for COPYSFX. The name of the
original file (input) and a name for the new copy.

So something like this would do:

copysfx /Users/James/Desktop/Ballad_FINAL_2_DENOISE_96\ 2.wav
/Users/James/Desktop/Ballad_FINAL_2_DENOISE_96\ 2_copy.wav

(all in one line obviously)

I haven't got it with me right now but I have a script at home for
batch copying files to a new directory with copysfx. I can email it to
you later tonight.

It uses the "foreach" tcsh command.

Best,

P

[peiman khosravi]

PS you can ignore the optional flags I think.

[peiman khosravi]

Another suggestion might be to try and save the output of RX as aif
instead of wav.

P

[Richard Dobson]

Also, it is worth building and installing libsndfile
(from www.mega-nerd.com/libsndfile); it includes a
handy diagnostic program "sndfile-info" (just give it the path of a
soundfile) which reports details of the structure of the file, noting
any anomalies. It is somewhat more comprehensive and thorough than the
little "sfprops" program included in the Toolkit. But to get the most
from it some knowledge of how WAVE files etc are constructed is useful.

Richard Dobson

[James Finnerty]

Thanks,

I'll also look into libsndfile - however, I have to say I'm impressed with the CDP command line utility. I'm not accustomed to working with audio files directly from Terminal, but this was a great way to discover how fast certain processes can be made. I'll definitely return to this utility when I need a fast way to encode ambisonics or even just to play back and analyze an audio file.

Peiman, both of your suggestions worked. Converting the file using "copysfx" allowed me to import the audio and produced a waveform that synchronized with the audio - however I still had to convert in Pro Tools in the final stage after a message appeared stating that the file had to be converted "because it is not BWAVE/AES31 compatible". This was similar to how the copy I made in Amadeus Pro was handled.

Finally, saving the file from RX to .aif turned out to be the best option. I could easily import the file with no error messaged, and it appears in Pro Tools in tact. So this is apparently the most painless solution...

Thanks for the assistance, all. In the end, looks like the RX .wav encoder was the culprit. Either that, or Pro Tools is missing some bit of coding that allows it to read a file encoded using RX.

Best,
James

Richard Dobson

--

[Richard Dobson]

What that means is (simply) that the files do not contain the extra
"Broadcast WAVE" chunk in the header; this holds meta-information about
the file, including some SMPTE-related data, plus originator and
date-stamp info. This is not something we have ever had a need/use for
in CDP (and indeed ignore whenever we read a file), but is central to
most audio production for, well, broadcast. Maybe we will add support
for it one day (when I have figured out all that SMPTE stuff). It
remains somewhat intriguing exactly what aspect of the original header
flummoxes Pro Tools in that way.

And yes, one of the best-kept secrets of command-line work is indeed
that it can be very fast!

Richard Dobson

On 30/11/2011 18:44, James Finnerty wrote:
> Thanks,
>
..