Weird problem with .wavs imported into Sonar from ProTools

[Malcolm Boyce]

I'm working on a project in Sonar that originated in ProTools. I have done this many times before but never experienced the problem that I detected on this.

The files are .wavs that were exported by a friend from his ProTools rig to a CDR, using what he believed was the same procedure that he has always used. Everything appeared fine until we went to O/D some tracks to the original session and a severe latency issue appeared on input to output. This happened upon starting playback of the tracks and not so much before.


As soon as I removed the tracks from the project, the problem disappeared. We figured that it was something with the files, so I removed the meta data from the .wavs and then everything worked fine.

Anyone else see this before, and anyone know how to avoid including the "bug" when exporting from ProTools?

[Improv]

try making a new session and importing all the tracks, copying all audio data.

[Malcolm Boyce]

As I said, the problem is in the meta data that came with the .wav files. Once you remove the meta data, everything is fine. Putting the files in a new project does not solve the problem. The files are the problem.

I was hoping to be able to tell my client how to avoid tagging his files this way in other projects. I know it is a mistake he has made, or something done differently from other times he has given me the same type of files.

[DivineMusic]

timestamp?
i had an issue like this a year ago going back and forth from pt to nuendo.... dont remember what the issue was

[Improv]

When you say he burned a "CDR"... would that be a data CD, or did he burn a redbook audio CD for the transfer?

[Malcolm Boyce]

Originally Posted by Improv

When you say he burned a "CDR"... would that be a data CD, or did he burn a redbook audio CD for the transfer?

I hope you're kidding...

[Melker]

Hello!

I recently had similar/related problems, when working in Sonar (6.2.1) with files recorded on ProTools HD. The problems where somehow of a different nature. Recording was done in 88.2 kHz, and when these files where imported into Sonar, some very strange things happend (audiocard lost its drivers... they dissapeared, and had to be reinstalled), and Sonar was not able to play the files. This happend when I imported the ProTools-recorded 88.2 kHz-files into a 88.2 kHz project in Sonar.

When importing the same ProTools-recorded 88.2 kHz-files into a 44.1 kHz Sonarprojekt, everything was working fine.

Even thou this is not the same problem as described above, my wild guess is that I should try to remove the metadata from the wavefiles, before importing into Sonar.

Question: How do I remove the metadata from the wavefiles?

/Melker

[Malcolm Boyce]

Originally Posted by Melker

Even thou this is not the same problem as described above, my wild guess is that I should try to remove the metadata from the wavefiles, before importing into Sonar.

Question: How do I remove the metadata from the wavefiles?

/Melker

I'm not sure about all editors, but I'm using Sound Forge, and if you open a file, and re-save it, there is an option to "save meta data" yes/no box to check.

I would hope most editors would have the same option.

I don't know of an easier way than this unfortunately.

Hopefully this will help you too.

[Improv]

Originally Posted by Malcolm Boyce

I hope you're kidding...

Check yer tone, Stewie. I'm just trying to help. Good luck with that.

[DontLetMeDrown]

I have had problems going the other direction. For some reason, some Stereo files that come out of Sonar randomly have problems in PT and won't give me the option to convert. The convert button is greyed out and it says, "File unreadable by Pro Tools". I'm not sure why this happens sometimes, but can be very annoying when transporting files to another location.

[minister]

Originally Posted by DontLetMeDrown

I have had problems going the other direction. For some reason, some Stereo files that come out of Sonar randomly have problems in PT and won't give me the option to convert. The convert button is greyed out and it says, "File unreadable by Pro Tools". I'm not sure why this happens sometimes, but can be very annoying when transporting files to another location.

Both Mac's and PC's involved?

always use wave files.

[Malcolm Boyce]

Originally Posted by minister

Both Mac's and PC's involved?

always use wave files.

I know with my situation they are BWFs coming from the Mac to my PC rig. It's just something that ProTools or the MacOS is tagging the meta data with, that Sonar is having trouble with.

We're still trying to figure if there's a way to get the files exported without the meta data, instead of having to add the step of removing it after the fact. We have transfered projects in the past without the issue, this is why we're hopeful it can be done on the ProTools end.

The interesting thing is, the meta data may be the source of different problems for different people, transferring files to and from different platforms. Definitely something to look at if you're having issues.

[Naren]

Originally Posted by DontLetMeDrown

I have had problems going the other direction. For some reason, some Stereo files that come out of Sonar randomly have problems in PT and won't give me the option to convert. The convert button is greyed out and it says, "File unreadable by Pro Tools". I'm not sure why this happens sometimes, but can be very annoying when transporting files to another location.

Isn't that a problem with Pro Tools not accepting Sonar's stereo interleaved files? I go back and forth with a Pro Tools studio and just assumed all along that I had to bounce a stereo file to two new tracks using the "split mono" option.

The files I get from the Pro Tools guy are always separate tracks for left and right of the stereo image.

By the way, I never "import" these files into Sonar from the File menu. I drag and drop the whole set of files at once from a folder into a blank Sonar session. Sonar then creates all the tracks and brings in the files one by one. It even converts to my preferred sample rate of 96kHz while it's doing it. Very convenient.

My apologies to the OP for possibly hijacking this thread. I've never experienced this problem you've described. You might want to take a look at the meta information from these files and compare to earlier files and see if you can find a difference. If such a thing is possible.

[Malcolm Boyce]

Re: the "stereo files" I always want them to come to me as "Stereo" tracks, as opposed to dual mono.

I don't believe we've had any problem going from Sonar to ProTools that way as well... Interesting though.

[PlatinumSamples]

Pro Tools creates correct RIFF files - if your app doesn't recognize a chunk it's meant to ignore it - contact your DAW manufacturer to report a bug in their software.

Rail

[Malcolm Boyce]

Originally Posted by PlatinumSamples

Pro Tools creates correct RIFF files - if your app doesn't recognize a chunk it's meant to ignore it - contact your DAW manufacturer to report a bug in their software.

Rail

What are "correct" files?

If the same version of Sonar didn't have problems before with files from the ProTools rig in question, and it all of a sudden does, that's Sonar's bug?

[PlatinumSamples]

As long as the metadata format is correct - any app should be able to use the WAV files. Are you suggesting that other apps also can't open these same files? Can you post an example somewhere and I'll check it out for you. Some apps choke on unexpected or unrecognized "chunks".. that's their bug - the WAV spec specifically states to ignore any unrecognized chunks. Basically there are 4 byte (FOURCC) chunk names followed by a 4 byte length value. If you don't recogninze the FOURCC, skip over the number of bytes specified to the next chunk, etc.

Rail

[DontLetMeDrown]

Originally Posted by minister

Both Mac's and PC's involved?

always use wave files.

Originally Posted by PlatinumSamples

As long as the metadata format is correct - any app should be able to use the WAV files. Are you suggesting that other apps also can't open these same files? Can you post an example somewhere and I'll check it out for you. Rail

Definitely using all wavs here. I do have an example stereo file that I KNOW will not open in PT, but opens in every other host. The file is like 60mb tho. I guess I can upload that if you want to check it out

[PlatinumSamples]

Hold on.. you said these were WAV files created in Pro Tools that won't open in Sonar -- now you're saying that you have a WAV file that Pro Tools won't open...??? (Edit - Oh, sorry different poster(s))

Sure post the file somewhere. Let's check it out. I take it these are PCM and not IEEE WAV files right. Pro Tools only supports PCM WAV files.

Rail

[Malcolm Boyce]

Originally Posted by PlatinumSamples

As long as the metadata format is correct - any app should be able to use the WAV files.

The problem is, Sonar is opening the files, and playing them back, and allowing plugs to run on them, and all the other associated functions. Everything appears to be fine, until you listen to an input and then you realize you have a peculiar latency thing going on. If you remove the meta data from these .wavs, the latency issue goes away.

Under "File Attributes" the new files from ProTools have: - ---- ---r
Under "File Attributes" my other files have: - --a- ----

What this means, I don't know.... but it's consistent with all the new files.

Other files I have received before from ProTools have had the second "attributes" line VS. the first line that's on the files that I just received.

You can see why I'm coming to the conclusion that the ProTools export is different from previous projects...

What I'm hoping to find out is, what has caused this change, and can we go back to the way it used to be? This client is someone who I have received projects from in the past with no issue, and he hasn't "upgraded" any software or hardware. The only thing he can figure is that he's changed something inadvertently and now can't think of what it could be.

Any suggestions? Does that line of "attribute" data mean anything to anyone?

[PlatinumSamples]

Post 2 files - one which is 'good' and one which is 'bad'.. and I can compare their metadata for you.

Rail

[Malcolm Boyce]

Originally Posted by Malcolm Boyce

Any suggestions? Does that line of "attribute" data mean anything to anyone?

Duh..... OK so I answered that one for myself. It's basically the "Read Only", "Hidden" etc properties of the file type. I was reading the files off the CDR, not thinking about the "ROM" nature of the disc.

Originally Posted by PlatinumSamples

Post 2 files - one which is 'good' and one which is 'bad'.. and I can compare their metadata for you.

Rail

Cool, I'll get something together for you to check out. It's just got me curious now, and it'll be interesting to see what's going on.

[Malcolm Boyce]

Update:

OK, so we found a difference in the procedure that my client used to export the files in question. I remind you that this person has exchanged projects with me in the past with no issues, and that's why we were puzzled by this.

The tracks were resampled on export in ProTools, by my client without him realizing what he had done. I chastised him accordingly. We know he did this for certain, and this is an obvious difference from previous projects.

I'm now going to do some more experimenting to see if the "nonresampled" tracks react a little better...

[Malcolm Boyce]

OK Rail, see what you find with these two files. They are the same track, exported to me two different ways. One is the original transfer of the tracks that gave me the trouble, and the other is the transfer without the "extra step" of resample AND bit conversion.

The new transfer isn't exhibiting the latency issue that the original tracks did.


Index of /TestFiles

For anybody looking to hear something cool, don't... It's a tambourine track...

[PlatinumSamples]

Technically everything's right - but try this:

https://www.platinumsamples.com/GS_T..._01-02.wav.zip

I changed a single value in the resampled file.... it will tell me what's up with Sonar.

Rail

[Malcolm Boyce]

That file seems to work on it's own, without causing the "problem".

I wish I had kept the original tracks all intact but I deleted the meta data in everything, never thinking that I might want to look at them again. At the time all I was thinking was fix the problem.

Basically, this has got me thinking that some problems that users are having, and I'm sure this isn't just a ProTools-Sonar thing, are related to things in the Meta Data. This is something that I wouldn't have thought of immediately, and in fact, wasted a lot of time doing what most would do: Making a new project and putting the files in, assuming the "project" was the problem.

The thing that really had us puzzled, until I found out about the "resample" was why projects from this same setup/client hadn't been a problem before. This is why I figured it was a settings issue or something, which as you can tell by the client's sample rate "oversight" is very understandable...

Right now I'm going to assume that in a straight transfer we won't be having any more problems. The word now is, meta data can manifest itself as latency, and possibly more "audio" issues, and is something we need to be aware of. I'm sure I'm not the only one who didn't know this.

[PlatinumSamples]

If that works fine - it's very possible that Sonar isn't working on frame boundaries. In the resampled file the data length was 1 byte less than the actual space the data took up... This is because Pro Tools correctly added a zero byte value to make the data an even value. If Sonar is relying purely on the data length value and not checking if it's odd or even (it should always be even) then it may be having issues.

That's the only thing I cam think of -- all I did was change the data length value by incrementing it by 1 to make the value even. Try using the original file and this one and see if they act differently in Sonar.

http://ccrma.stanford.edu/courses/42...ts/WaveFormat/

Cheers,

Rail