Timecodes problem (for mka muxing)

[rom1v]

Hi,

First, sorry if my english isn't good, I'm French.

I want to make an audio album encoded in FLAC muxed in MKA.

I had separated tracks, that I joined, no problem here.
Then I have to "chapter" the mka with timecodes.
That's where I have a problem.

Because I know how to chapter with TXT and CUE files, but the precision is "0.01 second".
But, for example, on a track:
976080 samples @ 44100Hz
it is equal to 0m22s13,333333333333333... and I can only write 0:22:13 : 975933 samples instead of 976080.

It's a small difference, but in that case, why make lossless files?

In fact, what I'm searching, it's a method to define timecodes in "samples" but not "time"...

I know we can make chapters with txt cue or xml, but I don't know XML, it's maybe the solution :)

If anyone can find a solution to my problem, very much thanks to him (or her ^^)

Thanks :)

[Mosu]

Originally posted by rom1v
I know we can make chapters with txt cue or xml, but I don't know XML, it's maybe the solution :)

The next mkvmerge version will probably have a resolution of up to 1ns with the XML chapter files.

[rom1v]

Originally posted by Mosu
The next mkvmerge version will probably have a resolution of up to 1ns with the XML chapter files.
OK, but why in ns instead of SAMPLE? sample has best precision...

[Mosu]

Originally posted by rom1v
OK, but why in ns instead of SAMPLE? sample has best precision...

Because Matroska's chapters are time based, not sample based. And with all due respect, ns is a MUCH higher resolution than a sample. For a sample rate of e.g. 96000 Hz each sample is 1000^3 / 96000 = 10416.666ns long.

[rom1v]

Originally posted by Mosu
Because Matroska's chapters are time based, not sample based.
OK

And with all due respect, ns is a MUCH higher resolution than a sample. For a sample rate of e.g. 96000 Hz each sample is 1000^3 / 96000 = 10416.666ns long.
Yes, I know, but if I want chapter at 976080 samples @ 44100Hz, it is equal to 0m22s13,3333333 (with ns precision)...
Do you think it will round exactly @ 976080 samples? If yes, great :)

I wait for the new mmg to test :)

[Atamido]

Yes, it will round to that exact sample. If you really want to understand it, there is a detailed explanation of how it works in the Matroska Specification Notes. (http://matroska.org/technical/specs/notes.html#TimecodeScale_Rounding)