I've been using the glue item function to trim down items to an exact length. However, i just noticed that the glued item does not null with the original! I have tried the "render to new take" option as well and get the same result. What gives? While this may be a minor issue in some situations, this can be a pretty serious problem for something like mastering where you want to trim down a file to be an exact length without changing the quality in any way.
Is there something I should be doing instead of gluing? Maybe some settings that I need to change? I really like a lot of things about Reaper but if I can't even do something as simple as trim and audio file without changing the source than I'm going to have to go back to using my previous DAW for any kind of 'professional' situation.
Sorry, but i have to ask...are you sure that its not just the parts that is not trimmed away from from the original that comes through when you compare the glued version to the original? Do you have any item-FX on the glued one? Or FX on one and not the other? Have you matched the volume perfectly?
If its not any of thet i am not sure what is going on to be honest...nulls completetly here.
Sorry, but i have to ask...are you sure that its not just the parts that is not trimmed away from from the original that comes through when you compare the glued version to the original? Do you have any item-FX on the glued one? Or FX on one and not the other? Have you matched the volume perfectly?
If its not any of thet i am not sure what is going on to be honest...nulls completetly here.
This is what i'm doing:
1. duplicate track with the file I want to trim
2. trim duplicated item (literally just the silence at the beginning and end; none of the audible material is being trimmed at all)
3. glue item
4. invert phase on the new item and solo both the original and glued item
5. play back original and triimed item soloed together
When I play back the duplicate and the original soloed together, I can hear pretty audible artifacts and there is movement on the master fader, which clearly means that the files are not the same. No FX, no difference in volume or panning, no sends or busses.
Unless i'm missing something, I suspect that this is some kind of bug with the reaper audio engine. Maybe it doesn't happen with all audio, but it is definitely happening with the audio I am testing it with.
Is project playrate or any item playrate != 1? That would suggest
different timestretch algorithms or at least processes applied
to each item.
Is the original item of different sample rate as the project? That
would suggest different resampling algorithms being applied
to each item (one real-time, one offline).
Is glueing function set to default settings in Project Setttings > Media?
If not, a format change (if lossy or of lower bit depth can be the
cause of difference in signal).
Otherwise there is only a possibility of some track automation,
routing, or user error when trimming that may suggest signal
being altered. If none of this covers your issue, please post a
demo project - just a .RPP file with two tracks to which you
applied your steps.
Have you got "Snap to project sample rate" in Snap dialogue settings enabled? If not, try that.
If something was moved or slip edited with snap off, you can have samples off their sample rate.
...or since not all tempos are going to correspond exactly to whatever sample rate, if you move the item to the grid, you can still end up with samples that are off the sample grid
When you glue or render, the rendered item will be always exactly on the samples, so the half-sample difference can cause the items to not null.
So yeah... he might try switching the ruler and grid to samples and zoom all the way in to make sure the samples aren't off the sample grid.
(filled samples work well for this )
other than that, I suspect there is a sample rate, playback rate, or pitch envelope at play here.
Is project playrate or any item playrate != 1? That would suggest
different timestretch algorithms or at least processes applied
to each item.
Is the original item of different sample rate as the project? That
would suggest different resampling algorithms being applied
to each item (one real-time, one offline).
Is glueing function set to default settings in Project Setttings > Media?
If not, a format change (if lossy or of lower bit depth can be the
cause of difference in signal).
Otherwise there is only a possibility of some track automation,
routing, or user error when trimming that may suggest signal
being altered. If none of this covers your issue, please post a
demo project - just a .RPP file with two tracks to which you
applied your steps.
e
Checked all of this and none of it covers it. I will upload a project with the file in question.
No fx, sends, envelopes or anything. I just duplicated the original track, trimmed a couple secs of the beginning and glued the item. I've even zoomed in and made sure that the files are aligned down to the sample. The check box in projects settings for using a different format for gluing is unchecked. Snap is to project sample rate is turned off. They are still not nulling.
Thanks everybody for trying to help get to the bottom of this. While the file that i'm having trouble is just a noise/fx bed where it doesn't matter that much if the file isn't perfectly the same as the original, my concern is for situations where audio integrity is crucial such as mastering.
I've even zoomed in and made sure that the files are aligned down to the sample.
Except they weren't.
Loaded it here at 96kHz and they were out by a smidgen, approx 1/4sample but enough to be just audible.
What sample rate is your project set at?
What sample rate does Alchemy work at?
Even though you rendered at 44.1 I cannot see where the misalignment came from without you're going to 192kHz.
This certainly doesn't happen here.
Steve
Nulls perfectly here too, this is a local issue. My guess is you've got your sound card running at a different sample rate to the project.
This seems to be it. I had though I had my interface at 44.1 but I guess something caused it to get changed to 48. I switched the sample rate on my interface back to 44.1 while the session was open and the files null now!
Glad this was just something on my end. Thanks guys!
While that did solve my issue, I am a little confused as to why the sample rate on my interface caused this to happen. I would imagine that the files should be identical regardless of what the sample rate on my interface is as long as the files are both the same sample rate and the project sample rate is the same as the files.
Heh heh, can I take this in a similar but slightly different direction. Normalization?
I've found that Reaper's Normalize doesn't null either.
Now before you say "of course, they are at different levels" let me explain.
Recently, I was following a discussion on another forum about Normalizing or not Normalizing. There were those that said normalizing totally destroyed the dynamics of an instrument while others said no it didn't.
Consequently I thought I would run some of my own tests in Reaper. Basically I loaded a Crash sample that was the lowest level of 32 samples, it was around -35.6db. Then I duplicated the Track with the sample and normalized the 2nd track. Then I adjusted the volumes so they were exactly equal (-35.6db) and put the 2nd track out of phase. I ended up with about -74db on the Master.
Of course there's no way to get the levels absolutely exact in Reaper, there's always the possibility they can have as much as .09db difference because Reaper works in tenths. Do you think that could cause the -74db difference?
I also jacked the level of the original Crash sample tack so that it had a -1 db output and then recorded that on another track. Those 2 tracks nulled out at -120db which wasn't bad.
So maybe normalizing isn't the best way to go with Reaper?
Sorry esosotericmetal, I'm really not trying to highjack your thread, I thought it was similar.
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
Quote:
Originally Posted by Tod
[...] Of course there's no way to get the levels absolutely exact in Reaper, there's always the possibility they can have as much as .09db difference because Reaper works in tenths. [...]
REAPER does not "work in tenths" - I think you're confusing two things here: how REAPER displays values on the GUI is not the same thing as how REAPER stores values internally. Have you ever tried opening a .RPP file in a text editor? If not, I can recommend doing so, as it can be very illustrative - and occasionally very useful for editing a value at a much higher precision than is displayed in REAPER's GUI.
REAPER does not "work in tenths" - I think you're confusing two things here: how REAPER displays values on the GUI is not the same thing as how REAPER stores values internally. Have you ever tried opening a .RPP file in a text editor? If not, I can recommend doing so, as it can be very illustrative - and occasionally very useful for editing a value at a much higher precision than is displayed in REAPER's GUI.
Thanks Banned, that may all be true and I have no doubt you're correct but that still leaves me with a meter reading in tenths.
Also, being able to set the fader to a higher resolution in the project file or even with the fader itself, doesn't do me any good in this case. I'm still left with the resolution of the meters for the two tracks.
I did take a look at a project file. I opened a new project, added one track, set the fader to around -1.7, and saved it. Then I opened it in Notepad and found the Track info, but couldn't find anything that made any sense as far as the fader setting. Perhaps you can make sense of it, do you see the fader setting below.
Location: Unwired (probably in the proximity of Amsterdam)
Posts: 4,868
Indeed. But perhaps you can also use other plug-ins or tools for metering?
I can't check this atm, but I'd guess the "VOLPAN 0.81373363031394" bit represents the value of the volume fader. Try setting it to some other value, saving again, and comparing before/after to see what changed. I don't know the exact formula for conversion, but there obviously is one. In any case, you did get my point that the display does not accurately reflect the actual value; I just wanted to clarify that distinction a bit, because one really should not rely on such truncated values displayed on the GUI in order to perform calculations with sufficient accuracy for the purpose of performing nulling tests.
Indeed. I can't check this atm, but I'd guess the "VOLPAN 0.81373363031394" bit represents the value of the volume fader. Try setting it to some other value, saving again, and comparing before/after to see what changed.
Well I did change the 8 to a 7 and indeed it changed the fader to -2.something.
Quote:
I just wanted to clarify that distinction a bit, because one really should not rely on such truncated values displayed on the GUI in order to perform calculations with sufficient accuracy for the purpose of performing nulling tests.
Yes, that's what I was getting at too, I'd really like to find a way to do this. It's starting to appear to me that all normalizing tools are not equal. In fact I'm starting to question normalizing period.
Under normal circumstances this wouldn't really matter to me, it's not that big of deal. However, after a person takes the time and expense to record good quality samples, it does start to matter.
Well I did change the 8 to a 7 and indeed it changed the fader to -2.something.
Yes, that's what I was getting at too, I'd really like to find a way to do this. It's starting to appear to me that all normalizing tools are not equal. In fact I'm starting to question normalizing period.
Under normal circumstances this wouldn't really matter to me, it's not that big of deal. However, after a person takes the time and expense to record good quality samples, it does start to matter.
The fader gain is worked with and stored as a linear gain. A gain of 0.5 would be displayed as a smudge less than -6dB.
Work it out: 20.Log10.A -where A is the linear gain.
I bet 0.81373 gain is -1.7dB (-1.79 actually, there you go)
The fader gain is worked with and stored as a linear gain. A gain of 0.5 would be displayed as a smudge less than -6dB.
Work it out: 20.Log10.A -where A is the linear gain.
I bet 0.81373 gain is -1.7dB (-1.79 actually, there you go)
Thanks planetnine, you're right, using this formula I'm getting pretty consistent readings.
db = 20*LOG10(VOLPAN)
Whether I'll be able to get the normalized track to NULL or not I'm not sure, but armed with this formula I'm going to give it a shot when I get the time.
Just thought I'd let you know, I did manage to get the NULL test for the normalized audio down to -111db. I might have gotten it a lot closer to NULL but it's too time consuming. I was making changes in .000001db increments and still getting fairly large volume swings.
Obviously the levels have to be exact to completely NULL. So unfortunately it's almost impossible to truly check out what normalization is actually doing.
So what does a person do when it comes to their all important samples, trust the normalizing tools at hand?
I think I'll opt to re-record the samples at the level I want, that seems to provide decent NULL tests.
i also attached a "simple" peak meter JSFX i made. it shows 6 decimal place "precision", and if you click on the "edit" box, you can see the values in the JS editor...(that goes for all the JSFX)
the values may not be 100% accurate (i think they are rounded/truncated), but what's important is that they are consistent.( i.e....useful for level matching) (just click a slider to re-set the meter)
i thought you might find it handy if you still have any interest in performing trivial audio tests like i like to do...
i also attached a "precision" peak meter (it's not "done" yet, but it works good enough) and a gain utility for if/when you need to add huge amounts of gain to something (i.e....hearing/seeing null test residual)
it's pretty much the same thing as Airwindows BitShiftGain, but with a wider bit range and an optional clip limiter, just in case you slip up and go too high...
Last edited by bezusheist; 04-08-2017 at 05:31 PM.