Imported audio file plays at double speed

I don't know a lot about WAV file formats, but it seems pretty clear there's something non-standard in the file header that is causing SONAR to misread the sample data. It might just be an uncommon format that the dedicated audio editors know how to read.

If you have a lot of files like this, it might be worth figuring out exactly what's going on, but if it's a one-time deal, re-saving the file from Audacity is a perfectly acceptable solution.

Where'd the file come from?

Where'd the file come from?

Downloaded from here:
http://www.indabamusic.co...uitar-solo-opportunity

It's the supplied backing track for a guitar solo contest (audio file "Not Again Contest Fade").  Most likely, it was originally exported as a mixdown from ProTools.  Nobody else seems to be having any problem with the file, but maybe I'm the only Sonar user.

But you might win if you play at double speed, they will be impressed!!
Did you import the file or try drag and drop. I find drag and drop is less buggy.

Cactus Music

Did you import the file or try drag and drop. I find drag and drop is less buggy.

I tried both ways.  I even downloaded a second copy of the file and tried again.  Same result.

rbowser

Under Global, Audio Data, File bit depths, Import Bit Depth - set that to Original.  I think that's the default, that's where mine's set, and audio always imports correctly - so - check that.

I have the same setting.

rbowser

Good morning, Kev - I see this still hasn't been figured out.  So odd that we're getting such different results.

I'm on Firefox, and I use Download Helper by Mozilla Firefox - When I'm on a page with media, the DH icon starts spinning.  On the contest page, I clicked "Not again fade" - then I clicked the DH icon.  It listed the same file name, but had it listed as an MP3 - and that's what I got after I clicked it to start the download.

On the page itself, no downloading was triggered when I clicked the file.  The song played, but the only way I could download it was with the Firefox DH.

I'm assuming that's the different element here, the Download Helper. - All I know is the contest MP3 sounds OK, and I've imported it twice and it played back perfectly.  But for the purposes of sounding as good as you can with your guitar lead over the track, naturally it would be preferable to have the .wav file.

Well - that's all I know on this --Hope it works out for you, Kev.

Randy B.

The info on the page that says to download the song you first have to sign up for the contest, so maybe the audio file streaming is a different format than the official contest audio file.

I wasn't able to download the file, maybe I need an account - but what a great concept! I'm surprised it's not been done before.

Chappel


I signed up and downloaded the clip and had the same problem as the OP. The wave file plays twice as fast... actually it sounds like it is skipping samples. Below is a comparison of the beginning of the original imported (dragging and dropping made no difference) wave file and one that was opened and saved with a different name in Audition. I circled some obvious transients to illustrate how they differ in each track.

Excellent detective work, Chappel - Well the folks running the contest need to be contacted.  They may be wondering why they're not getting any submissions.

Kev, if they don't fix the posted .wav file, looks like your only option is to grab the MP3 and work with that, since it works.  That might be OK since it's your own guitar work they'll be interested in hearing, and you can make that a good quality .wav file.

RB

Could this be a Broadcast WAV issue?

bitflipper


Chappel, are you sure the visible differences aren't because of the different zoom levels in each application? See if they are still as different-looking after matching the horizontal resolution.

Also, could you post the contents of the file header, i.e. from a hex editor?

Dave: I doubt it's a BWAV issue. The only difference is an extra data chunk that's simply ignored when not applicable. The bulk of the data is the same for BWAV and WAV files. The fact that it plays too fast suggests the sample rate in the file header may not match the actual recorded sample rate.

Anybody want to send me a copy of the file?

The two waveforms I posted images of are tracks 1 and 2 in the same project and are the same horizontal resolution. As far as I know I don't have a hex editor. Can you recommend a nice free one? I'd be happy to check it out.

I can send you the 20 MB wave file I downloaded. Just tell me where to send it.

Kev999

rbowser

Well, Kev - This MP3 is working for me, maybe it wouldn't for you, but it wouldn't be a hassle for me to upload it to my Box account, and I'd get the link to you.  Let me know if you want to try that.

Thanks for the offer, but not necessary.  I already have a "captured" copy as well as a converted copy that both play correctly.

Good deal, Kev - Now get crackin' on that lead guitar!
RB

It would appear that the file header is corrupt. If you have access to a hex editor, you can examine the header in detail and double-check my conclusion. You'll need a copy of the RIFF WAVE spec on hand, which is available online from many sources.

Most parts of the header look normal and identify the file as a stereo 44.1KHz 16-bit PCM file.

However, the field at byte offset 32 (decimal) looks suspicious. This field is defined in the RIFF spec as "BlockAlign" and is related to the number of channels and bits per sample. It caught my eye because this field contains a value of 8 in all of my 32-bit waves and a value of 4 in all my 16-bit waves, but contains 8 in the contest file even though it's a 16-bit file.

BlockAlign is the number of bytes for one sample including all channels. In a 16-bit file, there are 2 bytes per sample, or 4 bytes per stereo sample pair.

Setting this value to 8 would tell the player/DAW/editor that each sample value was twice the size it really is. This would cause the player to play back the file at double speed, skipping every other sample.

Since this information is only needed for playback, an editor such as Cool Edit/Audition might not necessarily need to use it, as appears to be the case given Randy's success loading it into Cool Edit.

UPDATE: I verified this theory by manually editing the file header and changing the errant "8" to a "4". The file then imported and played back correctly. I'd be curious to know what software they used, as it probably has a bug.

Everybody needs a hobby, I guess. Some folks crochet. I flip bits.

P.S. Kev, when you fix this problem and export your submission out of Sonar, don't create an mp3 of it. That submission form on the Staind site will not take mp3's for some reason. Save it as a 16/44 wave and upload, then submit and it will work. Good luck in the contest....I hope one of us wins it. :)

-Danny

Danny Danzi

Kev, I replied to your question on the Staind submission board as I put one up myself.

Thanks.

By now, my post thread has slipped down to page 6, having been overtaken by dozens of "hey, check out my submission" posts.