Allow me to notice something I never realized, and possibly nobody did ...
In order to understand, you should grab that EAC grid that shows the file offsets in bytes and the track times next to it. Now you tell me :
There are 44100 samples in one second, and since one "audio word" for one channel takes 2 bytes, one sample takes 4 bytes, so there are 4 x 44100 = 176400 bytes in one second. Track times are reported (by EAC) with a granularity of .01 (1/100) second.
1 sample takes 1/44100 seconds. We don't need to calculate more to see that the theoretical granularity needed is higher than EAC reports. What I say is this :
It is the data domain (the bytes) that determine where a track ends. This is a random offset in the file, as long as it can be divided by 4 (for 44100 files). Of course the base for my statement that this is "random" emerges from the fact that musicians don't stop playing at 1/100 second boundaries *and* that during the mastering process this isn't mapped onto 1/100 seconds either. The latter I actually don't know, because it might well be that the (software) consoles used work in the time domain, and that cutting and all is presented with a 1/100 second boundary. But hey, there won't be a law in this, so I take it this is *not* the case.
Need I say more ?
A Cue File composer like EAC will be using a(n unintended) virtual rounding of the end/start of tracks at 1/100 second boundaries, whereas it is not said at all that this can be reversed to the actual byte offset. Example :
We have a track that is reported (by EAC) to last 50.01 seonds. That means a byte offset of 8,821,764 bytes (50.01 x 176400).
In reality though, the track lasts e.g. 10 samples more, thus 10 x 4 = 40 bytes more = 8,821,804 bytes.
Now, when this track lasts 50.01 seconds, the next track (think gapless) starts at 50.02 seonds. And keep in mind : there is no better granularity like 50.01350 or whatever seconds. It's 50.01 or 50.02 and nothing in between that. So, the next track will start at 50.02 is byte offset 8,823,528. Uhmm, we missed 8,821,764 - 8,823,528 = 1764 bytes = (/4) 441 samples = (44100/441) = ... 1/100 second.
441 samples is way enough to let jump the voltage from e.g. completely negative to completely positive, whereas the music intended to let that slide by means of 441 steps.
Looking at beforementioned EAC grid again, this indirectly works out (or is worked out) differently : Where the byte offsets do not show a gap of even one (four) byte, the lot including the time domain is represented as :
|
| Track end | 8,821,763 | Time end | 50.01 |
| Track start | 8,821,764 | Time start | 50.01 |
The above implies that
a. The track ends 10 samples early (see above outlay);
b. The next track starts 10 samples early (no problem for gapless)
c. One sample is repeated.
Where the above example was about 10 samples being off, the maximum will be right in the middle of the 50.01 and 50.02, hence 50.005, or 8,820,882 - 8,821,764 = 882 bytes or (rounded) 220 samples. That is, if EAC rounds and not cuts (which we don't know).
Even when we're 220 samples off, this is never a problem, because when we's start an e.g. 3rd track of a gapless album, who will know that the 220 samples early or late start belog to the wrong track ? ... it just can't (be known);
When it's a non-gapless album, the 220 bytes (0.005 seconds) is way too short to end up in the previous or next track, knowing that the gap is in between 1 and 2 seconds.
Concluded : The only thing being wrong is that with two subsequent tracks playing while the music is gapless, one sample will be repeated without very special attention. This special attention means : start the track one sample later than the start time implies. And, since this would be wrong for the first track, this comes down to end the track one sample early. Too bad for the last track.
At the moment of writing this, I am dead sure that XXHighEnd applies the end at 50.01 and start at 50.02 syndrom, just because this is (was !) the most logical thing to do, and this is how the human being calculates. This means that for Cue Files, currently, 0.01 second will be missing between tracks ...
... which for gapless may incur for a tick because of voltage jumps which should be spread over 441 steps which is now done in 1 step.
PS: This is all *not* related to the tick and small repeat or echo which may be audible in Cue Files in between gapless tracks which shows in all versions u/i 0.9v-6a (and unofficial 0.9v6-b), which was caused by a calculation error in the time domain, which reformed an e.g. 0.09 to 0.90 (implying a very similar error as what this topic is about, although of a 10 times higher magnitude, but which is exactly what brough me to the subject here).
