KVR Audio

Kingston · Post by **Kingston** » Tue Apr 10, 2007 12:05 am

bduffy wrote:What are the "threads" for, anyway? Are those encoding passes?

no. it's a stupid feature for a programmer to leave there. it basically controls how multitasked (more than 1 file at the same time) conversions are spread to multiple CPU cores.

Kingston · Post by **Kingston** » Tue Apr 10, 2007 12:07 am

Funkybot's Evil Twin wrote:
Kingston wrote:why are you working on 16bit files by the way?
I'm using 16bit, because I'm assuming the samplerate conversion should come last

no. dithering should always come last. sample rate conversion nearly completely eradicates all benefits of dithering, especially since you're using a noise shaped dither.

you should always work on 24/32bits until the *very last* step in the project, which is a dither down to 16bits.

Kingston · Post by **Kingston** » Tue Apr 10, 2007 12:13 am

bduffy wrote:I was just going to say I tried this to: I got the same thing, about -0.5dB average difference.

what the..? how exactly do you guys measure? measuring the exact same spot of the audio and not just "sort of looking" at how the meters are moving?

wavelab audio file analysis always gives 100% reproducible results here, with r8brain as well. I still maintain there's something flawed with how you guys measure and/or use the meters here.

anyway, I give up.

[edit]

note that some spurious peak values can easily swing even 3dB between conversions especially on sharp transients. it's the reason we have oversampled peak metering in the first place. but RMS values should stay the same.

Funkybot's Evil Twin · Tue Apr 10, 2007 12:16 am

Kingston, I could e-mail you a portion (if not all of) both files.

I mean it's especially obvious to see just by looking at the waveforms here just by how clipped the originals are in the distorted guitar sections of the song. The waveform goes right up to zero in those sections in the original, and there's a substantial (1db gap) in the samplerate converted waveform.

As incredulous as it sounds, it is happening, and apparently reproducable.

Kingston · Post by **Kingston** » Tue Apr 10, 2007 12:17 am

go ahead. info AT michaelkingston.fi

bduffy · Post by **bduffy** » Tue Apr 10, 2007 12:25 am

Kingston wrote:
bduffy wrote:I was just going to say I tried this to: I got the same thing, about -0.5dB average difference.
what the..? how exactly do you guys measure? measuring the exact same spot of the audio and not just "sort of looking" at how the meters are moving?

wavelab audio file analysis always gives 100% reproducible results here, with r8brain as well. I still maintain there's something flawed with how you guys measure and/or use the meters here.

anyway, I give up.

[edit]note that some spurious peak values can easily swing even 3dB between conversions especially on sharp transients. it's the reason we have oversampled peak metering in the first place. but RMS values should stay the same.

Umm...the global analysis in Wavelab? The RMS comes out a little different, just a tiny difference, not 1dB. .

I see you edited...let me try this at home, could be the crappy card here.

Kingston · Post by **Kingston** » Tue Apr 10, 2007 12:31 am

bduffy wrote:Umm...the global analysis in Wavelab? The RMS comes out a little different, just a tiny difference, not 1dB. .

as it should be.

Funkybot's Evil Twin · Tue Apr 10, 2007 12:36 am

I'm sending you the files now Kingston. Should get there in about 20-30 minutes depending on my upload speed.

bduffy · Post by **bduffy** » Tue Apr 10, 2007 1:03 am

Kingston wrote:
bduffy wrote:Umm...the global analysis in Wavelab? The RMS comes out a little different, just a tiny difference, not 1dB. .
as it should be.

OK!

kylen · Post by **kylen** » Tue Apr 10, 2007 1:08 am

Funkybot's Evil Twin wrote:BTW, Kingston. Just tried it a THIRD time. EXACT same result! This 16bit, 88.2k file keeps getting reduced in volume (it's audible, visible, and the meters see it) by 1.1 dbs. In Audiomove I'm using these output settings: Format: .wav Rate: 44.1kHz Width: 16bit Fixed Quality: best, Threads: 1.

I'm scratching my head...

Did you just tell us the answer? I see the slight db diff in Adobe Audition.

Anyway I didn't hear much of a diff - not enough to worry with. I'm on a Creative soundblaster audigy2 ZS w/Beyer DT770 phones. I'll try the DT880's (they usually rattle my teeth) and report back. I need option #3 for the poll - "can't tell".

Funkybot's Evil Twin · Tue Apr 10, 2007 1:27 am

kylen wrote:Did you just tell us the answer? I see the slight db diff in Adobe Audition.

Anyway I didn't hear much of a diff - not enough to worry with. I'm on a Creative soundblaster audigy2 ZS w/Beyer DT770 phones. I'll try the DT880's (they usually rattle my teeth) and report back. I need option #3 for the poll - "can't tell".

That shouldn't have given away the answer as I didn't use the -1db version created with Audiomove (I used R8brain instead). And I did want to add a "can't hear the difference" option to the poll, but screwed up when creating it, and it wouldn't let me add it after the fact.

BTW everyone, the unmastered (empty mixbus) version is being uploaded to sendspace as we speak. Also, these files will be 24 bit uncompressed .wav's, so they'll be a little bigger, but more representative of the sample rate difference only. The order will remain the same to preserve votes already cast, and I'll edit the first post to include the unmastered link once I have it. I have my opinions about this second test, but I'll keep them to myself for now.

Kingston · Post by **Kingston** » Tue Apr 10, 2007 1:42 am

Ok folks Funkybot sent me the files and it's clear what's going on right now.

The 88.2khz file peaks at -0.1dB. When it's converted to 44.1khz this results in roughly 1dB higher peak *above* digital clipping near the end of the file. This is perfectly normal resampling behaviour and highly source material dependent. Audiomove normalises the resulting file as a safety measure, so it won't clip. R8brain will simply let it clip (but maintains file volumes).

I personally think there should be an option for this is, as it has potential to create worse volume differences and nasty surprises. On the other hand, at least it's safe!

The reason funkybots file causes this is probably due to the ancient t-racks mastering limiter which doesn't know how to prevent inter sample clipping. This is featured in just about every single modern limiter and should completely eradicate the need for audiomove to normalise anything. (it's also the reason I've never seen this normalisation thing before)

And there you have it.

Good catch (but not a bug).

Funkybot's Evil Twin · Tue Apr 10, 2007 1:48 am

Stupid T-Racks! That's it, I'm using GClip from now on! At least until I finally give in and buy Elephant.

Thanks Kingston!

Kingston · Post by **Kingston** » Tue Apr 10, 2007 1:50 am

there's still other potential causes for this, but t-racks being the last of the chain (and set to destroy as you said) is simply the most likely culprit.

one more reason to repeat this shootout without the mastering effects.

Funkybot's Evil Twin · Tue Apr 10, 2007 1:55 am

Update time: The unmastered/undithered version can be found here (the order is the same as the original as to preserve previously cast votes):

http://www.sendspace.com/file/6sn71c

I did make two tiny tweaks aside from turning all the junk off the master bus (I never claimed to know what I was doing when it comes to that anyway). First, I reduced the bias in Nick Crowe's Tube Driver on the overheads, and I also reduced the high-shelf on the overheads to +1.2 dbs.

I recommend downloading both sets of files before voting.

KVR Audio

Blind A/B Shootout: Upsampling Your Mix

Which is the upsampled version of the mix?