-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Decoder not parsing the direct output of the Encoder #65
Comments
Have a look at http://x42.github.io/libltc/ltc_8h.html#structLTCFrame There is a rising-edge at both ends. The transition at the start of the next frame marks the end of the previous frame. However this is only encoded at the beginning of the next frame. This is not usually an issue since LTC is sent as continuous stream of data, and even when the timecode does not change, it is common to repeat the last frame (rather than send silence. A loss of LTC signal is usually used indicate to a tape machine to unspool the tape). So in your example, you need call Also change the line -- |
Recent git now has a |
Wonderful - thank you so much for adding this. The time now appears to be decoded correctly, but the date (year/month/day) is missing / output as zeros. I've updated the code snippet above to reflect what I'm currently running -- is there perhaps an additional flag I need to set to encode the date? I tried |
Clearly I'm doing something dumb here. This is intended to be a very simple test of LTC encoding on macOS (arm64) - the code below is in Swift, calling directly to libltc through Swift's support for C interop.
Our intention is to generate (and playback) single LTC frames from our app when an event occurs, for timesync to that specific event from external cameras.
The code below generates a single LTC-encoded audio frame for the current time at a given fps/sample-rate, and then (as a sanity check) tries to decode that same frame (as stored in
buffer
). But the decode fails to parse an LTC, returning0
fromltc_decoder_read
. The actual values that the Encoder is writing intobuffer
for each sample are attached, and I've verified thatDecoder
does in fact read them appropriately when indexing intobuffer
in C-land. They seem at least superficially correct, as they're in the 38-218 range.EncoderSamples-44100Hz-30fps.txt
The text was updated successfully, but these errors were encountered: