RTSAFileTool start/end times for export?
Quote from andrew_s on 08/05/2024, 14:55I'm trying to use RTSAFileTool to extract a portion of a RTSA file, starting at a specified time until the end of the file, as a new RTSA file, like this:
RTSAFileTool.sh export -format=rtsa -start=11:10:43 input.rtsa output.rtsa
This works, but the output file is much shorter than it should be:
Reset Stream Clock
Reset Stream Clock
DSP to System time Offset: 2.45571e-05 sec
Starting
Progress: 100% [##################################################]
processed 2490368 samples
doneas the sample rate in the file 46.08 MHz, this is a duration of about 0.05 s whereas I'm expecting several seconds.
Trying again specifying an end time as well as start time results in an output of zero samples, even though the end time is later than the start time. If I specify only an end time and if the end time is beyond the end of the recording, it looks like it will export the entire input file (I didn't wait for it to finish to check). This makes sense.
Requesting information on the input file gives this:
RTSAFileTool.sh info input.rtsa
Reset Stream Clock
Reset Stream Clock
DSP to System time Offset: 1.33514e-05 sec
Number of Streams:1
Stream: #0
Start Time: Thursday, 14 October 2021 10:53:17 BST (1634206185.398543) End Time: Thursday, 14 October 2021 11:11:06 BST (1634206266.652362)
Samples: 3,744,202,752 Payload Bytes: 29,953,622,016It's unclear to me whether I should specify the start/end times to RTSAFileTool as local time (BST in this case) or UTC, but it doesn't seem to help if I use UTC. Also, the Unix time shown in parentheses after the "Start Time" above does not correspond to the start time shown.
Has anyone else experienced this problem?
RTSA-Suite Pro version 2.5.1.14350 on Ubuntu 22.04.
I'm trying to use RTSAFileTool to extract a portion of a RTSA file, starting at a specified time until the end of the file, as a new RTSA file, like this:
RTSAFileTool.sh export -format=rtsa -start=11:10:43 input.rtsa output.rtsa
This works, but the output file is much shorter than it should be:
Reset Stream Clock
Reset Stream Clock
DSP to System time Offset: 2.45571e-05 sec
Starting
Progress: 100% [##################################################]
processed 2490368 samples
done
as the sample rate in the file 46.08 MHz, this is a duration of about 0.05 s whereas I'm expecting several seconds.
Trying again specifying an end time as well as start time results in an output of zero samples, even though the end time is later than the start time. If I specify only an end time and if the end time is beyond the end of the recording, it looks like it will export the entire input file (I didn't wait for it to finish to check). This makes sense.
Requesting information on the input file gives this:
RTSAFileTool.sh info input.rtsa
Reset Stream Clock
Reset Stream Clock
DSP to System time Offset: 1.33514e-05 sec
Number of Streams:1
Stream: #0
Start Time: Thursday, 14 October 2021 10:53:17 BST (1634206185.398543) End Time: Thursday, 14 October 2021 11:11:06 BST (1634206266.652362)
Samples: 3,744,202,752 Payload Bytes: 29,953,622,016
It's unclear to me whether I should specify the start/end times to RTSAFileTool as local time (BST in this case) or UTC, but it doesn't seem to help if I use UTC. Also, the Unix time shown in parentheses after the "Start Time" above does not correspond to the start time shown.
Has anyone else experienced this problem?
RTSA-Suite Pro version 2.5.1.14350 on Ubuntu 22.04.
Quote from mm_dev on 13/05/2024, 11:42Unfortunately the timestamp semantics here are a bit complicated and not really intuitive:
When using the info command, the displayed "Start Time" refers to when the originating stream was started (e.g. when the Spectran V6 started), not the start of the recording. The unix timestamp value in parentheses though refers to the start of the recording instead. For obvious reasons the values do match in case of the "End Time".
When using -start and/or -end, the passed arguments are not absolute times but relative to the start time of the stream (NOT the recording).
So in your example where you wanted the export to start at 11:10:43 real time, the correct value for -start would have been
00:17:3400:17:26. Specifying the absolute time resulted in the selected start being beyond the end of the recording, which is undefined behavior and resulted in only the last received packet being exported (which then got chopped away by the endtime argument eventually).
Unfortunately the timestamp semantics here are a bit complicated and not really intuitive:
When using the info command, the displayed "Start Time" refers to when the originating stream was started (e.g. when the Spectran V6 started), not the start of the recording. The unix timestamp value in parentheses though refers to the start of the recording instead. For obvious reasons the values do match in case of the "End Time".
When using -start and/or -end, the passed arguments are not absolute times but relative to the start time of the stream (NOT the recording).
So in your example where you wanted the export to start at 11:10:43 real time, the correct value for -start would have been 00:17:34 00:17:26. Specifying the absolute time resulted in the selected start being beyond the end of the recording, which is undefined behavior and resulted in only the last received packet being exported (which then got chopped away by the endtime argument eventually).
Quote from andrew_s on 13/05/2024, 17:06Thank you. Let me make sure I understand this. The times in the file are:
start of stream (mStartTime in the 'STRM' chunk): 1634205197.937217
start of recording (from first preview chunk): 1634206185.398543
wanted start time 11:10:43 BST (10:10:43 UTC) = 1634206243 (in UTC)
Therefore the time required for "-start" should be 1634206243 - 1634205197.937217 = 1045.062782526016 or 0h 17m 25.063 s (00:17:26.063)
That almost agrees with what you quoted above, except that I get 26 s not 34 s. Am I still missing something?
Thank you. Let me make sure I understand this. The times in the file are:
start of stream (mStartTime in the 'STRM' chunk): 1634205197.937217
start of recording (from first preview chunk): 1634206185.398543
wanted start time 11:10:43 BST (10:10:43 UTC) = 1634206243 (in UTC)
Therefore the time required for "-start" should be 1634206243 - 1634205197.937217 = 1045.062782526016 or 0h 17m 25.063 s (00:17:26.063)
That almost agrees with what you quoted above, except that I get 26 s not 34 s. Am I still missing something?
Quote from mm_dev on 13/05/2024, 17:38Sorry, looks like I made a minor error in the calculation, that's what you get when doing timestamp math on the fly 😉
Your result is correct.
Sorry, looks like I made a minor error in the calculation, that's what you get when doing timestamp math on the fly 😉
Your result is correct.
Quote from andrew_s on 14/05/2024, 13:57No problem, thanks for confirming!
If you could update the documentation on RTSAFileTool linked here https://v6-forum.aaronia.de/forum/topic/rtsa-suite-pro-file-format/
under the RTSA format documentation, with details of how the start and end time are defined, that would be great.
Thanks again for your support.
No problem, thanks for confirming!
If you could update the documentation on RTSAFileTool linked here https://v6-forum.aaronia.de/forum/topic/rtsa-suite-pro-file-format/
under the RTSA format documentation, with details of how the start and end time are defined, that would be great.
Thanks again for your support.