A sample can be “all zeroes” if that’s what you mean. Other than that your question doesn’t really make sense.
Also, when you say “file size” people are going to think you’re talking about the size of for example a .wav file. That seems to be different from what you’re talking about when you write “it can end wherever”. So it’s a bit confusing.
Again though your point is taken (by me): “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.” If that’s true then yes it’s odd.
On the other hand - and yet again - it’s really hard to see what’s going on in your examples because we don’t have the same frame of reference. “115”, “116.3” and then nothing in the third. I have no idea what those numbers would mean. I don’t know how far you’ve zoomed in in each example and if that matters. I don’t know what the BPM is… etc…
the last two animated gifs are the exact same jsut the zoom isn’t matched. The first of the two animated gifs, is simply showing that the Export Audio bounce ended short of the bar. The second of the two animated gifs shows me ‘Bounce Event’ to correct the error.
So yes, my main interjection here is… If Audio Export has to abide to exact sample position, why does ‘Bounce Event’ not?
If zoom levels are different then it’s very hard to tell if things are the same or different. So if you export and it doesn’t do what you want and then you bounce then you need to be zoomed into the same level both times so you can be sure that there isn’t that gap in both cases. If in the second case you’re zoomed out for example I would bet it could appear as if there’s no gap even though it’s there if you zoom in.
the zoom is irrelevant… or maybe you have either a tiny screen or a very high resolution and can’t see the images properly? I’m not sure what you’re getting at with the zoom.
In this image, I am showing with the cut tool and cursor, that after exporting a cycle marker range which was perfectly set to the bar, the exported audio came back short.
In this image, I am showing that came-back-short audio and me fixing that error gap by range selecting and bouncing the audio to the exact needed length - this renders the audio and the small empty space to form a new audio file/event without that error… meaning, somehow, by your guys’ description, a fractional sample has been created, or is somehow virtually emulated.
I can confirm that exporting audio events using export cycle markers or using RIP sometimes adds a sample causing unpredictability in the precise length of the resulting audio measured in samples (this is exporting with no audio processing involved). The issue seems to depend on where the audio is placed along the time line relative to frames. The problem has been around for years. It may be a so-called unavoidable mathematical side effect of the algorithm used to do this operation but, personally, I would consider this a bug. I see no reason why a user should not expect the result of a simple audio export to be identical in length to the original.
Actually, the export is identical to the original. It’s just misleading, to make you think that you are selecting fractional samples, when in fact you are not. Think about it as selecting files in a file browser, a file can either be selected or not selected. The same happens on the Cubase timeline with audio samples.
To make matters more confusing, Cubase allows an audio event to have a length with a fractional-sample at the end. This is purely visual. The underlying audio file’s length still ends with a full sample.
It is certainly not always the case that the length in samples is identical to the original. It depends upon where the audio is placed on the timeline at the time of the export. Please note that I am referring to the length in samples and nothing else.
For example, in a 48kHz 24bit project place an audio event of 96000 samples in length at sample number 290975 on the timeline and use RIP to create a new audio event. The newly created audio event will be 96001 samples in length. There is no issue of fractional samples here. The original begins and ends on precise sample divisions on the timeline. One sample has been added to the end of the resulting event which also begins and ends on precise sample divisions on the timeline. Nothing more nothing less.
Now take this same audio event and move it back by one sample to sample number 290974 on the timeline and do the RIP operation again. The resulting audio event is now 96000 samples in length.
How did you move the original audio event? Unless your grid is set to samples and “snap to grid” is engaged, there’s no way to place an event precisely with a mouse. If you place a 96000-sample long event in between the greed, you will always get 96001 samples after rendering.
When the grid is set to samples, the counter doesn’t show fractional sample positions, so you may believe an event to be aligned with the grid, but it may not be the case.
You seem to be wanting to introduce an error into the test I have outlined, rather than conducting the test yourself. I did indeed set the grid to samples with snap to grid active. I could not have stated it any clearer… I wrote ‘The original begins and ends on precise sample divisions on the timeline’.
You also seem to be preoccupied with ‘fractional samples’ or ‘fractional sample positions’. Yes I agree that fractional sample positions also produce the same issue. But the issue raised by lovegames is not related only to fractional sample positions. If you’d care to take the time to conduct the exact same simple test I have outlined above in Nuendo you will see the same result… and no ‘fractional sample positions’ involved.
