Export at 44.1khz
Another Export result 88.2khz
I don’t understand why this would be the protocol, when I can do a normal event bounce just fine?
This in Cubase, asking if same is in Nuendo?
How else should it be? A sample is the smallest time division of your audio file. It would be wrong to make the file shorter, so any DAW has to round up.
Then how is it that bouncing an event doesn’t need to do this and export does? You see in the the 3rd gif, I do a typical event bounce and it doesn’t need to round up or down.
How are people going to create precise loops within certain BPMs? If they are slightly off, they won’t duplicate or loop properly to grid?
I don’t have an answer to this, but an exported audio file cannot have a fractional sample at the end. At 44.1kHz we are talking about less than 0.02ms, so it will be a less-than-2ms-difference on 100 repeats of your loop. You won’t hear the difference.
Okay so Audio Export must only work to some sort standard like redbook or something.
We should have the option to change this in export. Give us two different methods. Or when ‘Create Audio Track’ is enabled or something.
I don’t like this because it will potentially engage time adjustment algorithms without me knowing or wanting.
I think what Sugar is saying is that you simply cannot have a partial sample. The sample theorem doesn’t allow for it and neither do software and hardware.
A partial sample = a higher sample rate practically speaking. So if you’re working at 44.1kHz and you have a range that ends one quarter sample too late then the only other solution would be to switch to 176.2kHz. And when you do that you tax your CPU harder and you have to recalculate everything, especially filters.
I just don’t see how this is possible to do on the fly for any DAW. And it’s a bad idea.
I know what Sugar is saying, what I’m saying is that, you have “partial samples” all the time when bouncing events as I’ve just shown above.
I understand what is being said, but gif3 contradicts what you are saying at the same time.
Well it’s hard to see what you’re doing because the only numbers I see are different for the respective .gifs, so I can’t even tell if you’re working on the same thing in the same timeline under the same circumstances. It looks to me though that even that last .gif where you’re bouncing does the same thing. The actual files end slightly before the vertical line, your selection then actually extends to that vertical line when you make the selection, and the new events are thus consolidated to that line. It’s hard to see if you’re looking at the selection range and then what results from bouncing, because they end the same place (at the line), but before then there seems to be a small gap between the end of the event and the line - and that gap is ‘closed’ as you make your selection.
But anyway, the only reason I can think of why you’d see a difference is that your sample rate is higher in your project compared to your export, or if you exported to some lossy compressed format like mp3 and then reimported that, rather than stick to for example .wav files.
No, in the last gif, you are clearly seeing it bounce to grid.
This is happening all the time in your projects - different BPMs aren’t going to line up with the sample rate.
Obviously this problem would become more noticeable if you are working at 44.1 and experimenting with a 30 bpm
I’m not sure you see what I’m saying (or the other way around). The way that last gif looks to me is this:
-
You have four events - none of them are selected and all are some sort of orange color (whatever). The end of the events is NOT at the vertical line. It is before the line. There seems to be a gap between the end of the events and the vertical line.
-
You drag in from the left toward the right a highlight over those four events. That’s the light-blue area.
-
You do something (that I don’t do) with your tool and the selection now extends to the right. At first I thought this selected the events only, but when I looked closely that’s not what I see. What I see is that the selection snaps to the ‘vertical grid line’, meaning the end of the light-blue area is right at the vertical grid line - not before, not after.
- you now still have a gap between the end of the event and the vertical grid line, and the end of your selection appears to be where the grid line is.
-
After you bounce the events they turn dark. End of those events that have been bounced is now where the grid line is. This is different from where they ended before.
-
You seem to do something, I guess switch from range tool to selection tool, and that removes the selection area but leaves the events ‘highlighted’ in dark.
-
Watch the end of the events as the .gif loops back to the beginning again - to my eye the end moves to the left.
→ So unless I’m misunderstanding you all examples show how the events end at one place in the timeline, and then after you’ve either exported or bounced them they end at a different location.
Well if the “problem” is quantizing to sample rate then it is what it is. Nothing to do about it.
But there’s actually another thing to consider here: If the ‘issue’ is lining up to samples then you’ve never heard it 100% the way you’ve seen it anyway. Since there simply is no way you can place something (samples) between samples it means that when you press play you will at best hear what is being exported anyway. Anything other than that I would assume would need a higher sample rate.
No gifs loop. you’re seeing the animation restart.
“4. After you bounce the events they turn dark. End of those events that have been bounced is now where the grid line is. This is different from where they ended before.”
is the last step - they bounce, and render the audio file to the specific length of the bar of which I had intended to originally export. You are looking at me re-bounce exported files that got cut short (or in the original image example, went longer than intended)
WAV files are sort of a lossless container aren’t they? You can have a samplerate up to 4.3 GHz. I don’t think the actual size of the file has to be constrained to the encoded sample rate
Same thing. Audio can loop. Video can loop. The gif loops the video. I.e. the “animation restart”.
K. To me that was very unclear.
I would wonder just what the audio looks like inside the various events. In your case I would think you’re not gaining anything in the last example since the “error” is already baked into your exported files. In the earlier examples I’d be curious to see what the content of the events would be like if you didn’t export but instead bounced them both as long as they already are (assuming that’s possible) and to the extended range that the export would have given you. I’m guessing that looking at what’s in the bounced events should show you something about how Cubase is adapting actual audio according to each scenario.
Correct.
So back to the earlier question you had:
As long as you select according to the grid which in turn is depends on tempo I would expect things to loop just fine. If this is all depending on sample rate “quantization” (for lack of a better word) then any discrepancy that exists will be neutralized every time the section restarts. So if you have a four bar loop you select it according to the actual grid, not your events, and you loop those four bars. At the end of each loop you would hypothetically have an “error” but it would never accumulate because the next time around it isn’t a loop of the first four bars, it’s a copy starting on the next “accurate” downbeat.
That to me appears to be how you would get around this.
Our exchange is getting a bit too complicated here. Whatever the discrepancy is here, between exported files and bounced events and samplerate vs BPM… I don’t like it. I don’t think NASA would accept such a protocol discrepancy to be floating around in their systems.
Either there needs to be an option in Export Audio to automatically make these adjustments, or the protocol just should not work like this at all and it should exactly as ‘Bounce Events’ does.
As long as you select according to the grid which in turn is depends on tempo I would expect things to loop just fine. If this is all depending on sample rate “quantization” (for lack of a better word) then any discrepancy that exists will be neutralized every time the section restarts. So if you have a four bar loop you select it according to the actual grid, not your events, and you loop those four bars. At the end of each loop you would hypothetically have an “error” but it would never accumulate because the next time around it isn’t a loop of the first four bars, it’s a copy starting on the next “accurate” downbeat.
I appreciate the solution potential you are giving, but your solution is based of presuming how I am wanting to use these exports… Whereas my concern is a little bit more general or broader than that, looking at the wide range of variables… MediaBay… Sample/Loop library creation… Archiving… phase alignment… loop stacking… avoiding stretch algorithm being automatically engaged… setting BPM based off file… Using in VSTis… etc…event snap editing snapping to wrong spot
The other issue with your solution, is the annoyance of even having to check this. Is it short? is it long? The error is so small that you wouldn’t be able to see it without zooming in a fair amount. That bugs me. I am just wrapping up a 3000 loop project utilizing cycle marker export…
The attraction to exporting by cycle markers is obviously the speed of being able to automate multiple sections of loop across multiple tracks while also utilizing the naming attributes and having that part of an automated process.
There needs to be an option, or cycle marker export should be to exact file size even if silence is being inserted as the last chunk.
You don’t have to check anything if what you’re doing is triggering a loop every X beats, as opposed to duplicating it serially over a timeline by having each new loop begin when the other ends. Having said that of course there could be use cases where perhaps this turns into an actual problem.
Either way you should really talk to tech support about this, or get some programmer to respond to your concern, because me and the other person are operating under the assumption that this is related to samples and not something else.
I dont want to have to think about avoiding one method of utilizing a loop over another because of this. I have thought of all these things already myself - I’m just trying to figure out why, if it’s a bug, if it’s bad code protocol on Steinbergs side, do other DAWs do this, etc.
It doesn’t make sense to me that Bounce Events can ignore sample positions but Export Audio Track cannot at all, even if ‘Create Audio Track’ enabled.
There’s nothing wrong with Steinberg’s code. All digital audio devices work the same way (well except DSD, but it’s not applicable in your case).
No DAW or audio card or digital looper can play fractional samples. No digital audio file has a length with a fractional sample at the end. What you see in your DAW is just a graphical representation, which allows you to see those tiny rounding errors, but it’s not what you actually hear. If you can’t live with this discrepancy, you can start using tempo values which perfectly match the sample rate. In any case, you won’t hear the difference.
I think Samplerate and file size are two different things no? a Wav file can be shorter than sample up to the actual data rate max of Wavs is 4.3ghz. a Wav is just a container for encoded audio data no? The samplerate dictates how much resolution you are going to fit within the container. Each Wav can fit up 4gb (or one second of 4.3ghz)… Does the file size really have to be exact sample length? do you know that for sure?
When bouncing an event it is the file size you are adjusting. It can end wherever.
Surely, the export protocol must be adding silence. or removing it?
And how is it avoiding pops/clicks in making this decision if my fades are starting from "fractional sample?
I’m not sure where you get this information from, but every uncompressed audio file has it’s specified sample rate. Otherwise your computer wouldn’t know how fast to read each sample, or if a sample rate conversion is needed to play it correctly.
File size is irrelevant, it just depends on the number of samples. Sample rate and bit depth describe the speed and size of the samples in your audio.
And yes, every audio file has only full samples, no fractions at the end.
Does silence count as a sample, or is it ignored?