In the TOC and CUE files generated by Ardour, I get timing markers that are ahead of my tracks () compared to my CD markers in Ardour, which makes the TOC and CUE files unusable for extracting my tracks from the global WAV file.
Does anyone have an explanation/solution?
It does indeed seem to be buggy or at least visually misleading.
Using a self compiled linux version of 8.12 and the ALSA backend I placed CD markers at
00:01:53:29
00:02:36:00
00:02:59:01
and the resulting cue was
FILE "5_session.wav" WAVE
TRACK 01 AUDIO
FLAGS DCP
TITLE "cd trk1"
INDEX 00 00:00:00
INDEX 01 01:53:74
TRACK 02 AUDIO
FLAGS DCP
TITLE "cd trk2"
INDEX 01 02:36:00
TRACK 03 AUDIO
FLAGS DCP
TITLE "cd trk3"
INDEX 01 02:59:02
I tried the same using Pipewire 1.5.81 and got similar result with markers at
00:01:33:00
00:02:03:15
00:02:25:10
producing
FILE "4_session.wav" WAVE
TRACK 01 AUDIO
FLAGS DCP
TITLE "cd trk1"
INDEX 00 00:00:00
INDEX 01 01:33:00
TRACK 02 AUDIO
FLAGS DCP
TITLE "cd trk2"
INDEX 01 02:03:37
TRACK 03 AUDIO
FLAGS DCP
TITLE "cd trk3"
INDEX 01 02:25:25
So it seems that markers placed on the precise second (00:02:36:00 and 00:01:33:00 in my examples) produce a correct cue entry but markers that are âoff secondâ are incorrect.
Another thing is that Ardour seems to think there are only 30 milliseconds in a second.
If you place the playhead right before a beat line it reads, say, 00:02:57:29 and if you then move it a smidge to the right it reads 00:02:58:00.
These things could be related in that the toc/cue could be correct but the visual representation in the Edit window could be a bit off.
Have you verified that the tracks actually start at the incorrect time?
Ardourâs primary clock defaults to displaying timecode at 30 frames per second. To see milliseconds, you need to change it to Minutes:Seconds mode - The Ardour Manual - Editing Clocks. Also, CD track markers are always aligned to 1/75 second boundaries: if you select a grid of âCD Framesâ you can snap markers exactly to where the exported TOC & CUE files will place the track indices (though currently there are some idiosyncracies to this grid mode: 0009180: 'CD Frames' grid foibles - MantisBT).
@trelin1 I donât know whether this can explain your problem, though. How far ahead are the TOC & CUE markers from where you expect them?
Thank you for your answers.
All my clocks are set to Minutes:Seconds mode.
In Ardour the start point of my first track is at
00:02:01.310.
The corresponding value generated in the CUE and TOC files is
02:01:23.
What does the number 23 correspond to in the TOC and CUE files? (It is not a number of images, since I also get corresponding numbers > 30 in the files. If I convert 23 to thousandths of a second, I get the number 383, but I am not accurate to thousandths of a second).
The problem is that the track extracted with the K3B interface or with the shnsplit command starts about 9 seconds before the marker indicated in Ardour.
Since both extraction tools give the same advance, I assume the problem comes from Ardour.
I should point out that the sampling frequency of the session is 48kHz, if that matters.
The fractional second part of the timestamps in TOC & CUE files are in CD frames, which are 1/75 of a second.
I donât know for sure what will happen if you export CUE or TOC with an exported sample rate of anything other than 44.1kHz, but I would not be surprised to find timing discrepancies. CDs are always 44.1kHz sample rate & 16 bits: if youâre exporting TOC or CUE, make sure the export format matches this - The Ardour Manual - Export Format Profiles.
I tried exporting at 44 kHz, but I get the same result. The original session is at 48 kHz. That may be where the problem lies. Iâll have to run a test.
That .310 to :23 conversion works out, if my understanding is correct.
If a CD frame is 1/75 second then 23 frames is 0.306 seconds and thatâs the closest it can be to .310 since 24 frames would make it 0.320 seconds
If your track is 9 seconds off the marker thereâs clearly something else going on.
I ran shnsplit on a 44.1 kHz wav I exported from at 48 kHz session in Ardour 8.12 and those split tracks started at the intended points in time.
I just ran the test from an open session with a sampling frequency of 44.1 kHz. This time, the start points of the extracted tracks corresponded to the markers defined in Ardour.
This means that this type of extraction can only work from a session initially opened at 44.1 kHz in accordance with the CD format. With a different initial frequency, the marker calculations are skewed.
not in my case, sorry âŚ
Itâs probably something strange on your end.
What version of Ardour are you running and what OS?
It works fine in my self compiled 8.12 on Linux with Pipewire 1.5.81
I thought it could be that the first test I ran was only a 4 minute session but I tried it on a 20 minute one at 48 kHz, with a marker at 17m 18s, and that was spot on as well when I split the exported 44.1 kHz file with shnsplit
jâutilise Ardour 8.4.0~ds1
There was a lot of work in time handling in the 8.x releases, it would be worth re-checking in 8.12.
Understood, I will update Ardour when the time comes. But getting the right markers in the TOC and CUE files will not be enough to achieve my goal.
I did a continuous live recording session. Now I want to extract the strictly musical parts (excluding applause, etc.) into separate audio files that will eventually be burned to CD, if possible with silences separating the different tracks.
The cue file does not seem to allow separate tracks to be extracted from the session, as there does not appear to be an end marker for track n other than the start marker for track n+1.
To get around this first problem, it is always possible to insert a ghost track between two tracks to be extracted, but this creates another problem. The audio files obtained with the shnsplit tool contain an extra 10 seconds after the start of the next ghost track, which I assume corresponds to the silent tracks that separate the songs on a CD. So I end up with a bit of the applause from the ghost track that I wanted to delete after the music track.
The toc file does contain the end-of-track information, but the cdrdao command seems to be designed exclusively for burning CDs and does not allow the desired tracks to be extracted into separate files.
I could also export the different sections directly from Ardour, but in that case, the loudness normalisation does not work for the entire session, and I end up with different audio levels between the exported files.
The only solution for me at the moment is to export the entire session into a first file to obtain global normalisation for the whole session, then re-import the normalised audio file to export the tracks Iâm interested in without normalisation, framing them with short silences so that I can play the files one after the other on my PC and possibly burn them to a CD.
This is all extremely tedious. Please let me know if there is a solution, I am just a poor self-taught amateur.
Many thanks. Francis.
Translated with DeepL.com (free version)
Split the track in Ardour and place each section at the appropriate place and with the appropriate spacing before adding the CD markers and exporting.
I donât think shnsplit will add extra silence to the split file unless youâre using the -e or -u flags.
If you want to split the track after exporting you should use something like
shnsplit -f file.cue -t "%n" file.wav
to get 01-file.wav, 02-file.wav and so on.
But if youâve already prepared the track in Ardour before exporting you really shouldnât need to split anything since the silence you want would already be there in the cue file.
OK, thank you for your reply.
Strangely enough, the markers generated by Ardour in the CUE files are now correct (though I canât explain why).
From your answer and my own research, I understand that it is not possible to mark the end of a track other than with the marker marking the beginning of the next track and, therefore, that it is not possible to delete an interval between two tracks that we do not wish to extract.
This means that tracks must be cut and pre-positioned before generating the CUE file, which is really inconvenient. Itâs a shame that we canât redirect the output to files using the cdrdao command and a TOC file that is capable of identifying the end of the tracks to be extracted.
For my part, in order to preserve the integrity of my tracks recorded in Ardour, I preferred to use Audacity to remove the pre-gap intervals added at the end of each file with the shnsplit command and replace them with 2 seconds of silence. Itâs a bit trivial but relatively easy to do.
I could also have re-imported the global wav exported for the sonie and made the cut in an additional track, but that would have forced me to modify my previous markers, or I would have had to open a new session just for that. Audacity was probably the best solution to minimise the work involved.
Thank you again for your explanations, which confirmed my reasoning.
Do you need to keep a session with all of the non-musical recording intact? If so you could either save as new session, or create a snapshot and switch to the snapshot. In the new session or snapshot you can remove the sections you do not want on the CD.
Look for âripple editingâ in the manual, it makes positioning the new regions more convenient, because when you delete the regions of non-musical audio you do not want, the remaining regions move together to fill in the time which was previously taken by the removed region.