Many videos files are now beyonds 30fp. For example 50fps or 60fps. MTC only supports up to 30fps,
isn't it time to update the MTC specification to support higher frame/sec ? The first MTC byte uses two bits now to specify the frame rate and the others bits are unused. Modern DAWS support MTC, but can't sync the new video files due to MTC's limitation.
isn't it time to update the MTC specification to support higher frame/sec ? The first MTC byte uses two bits now to specify the frame rate and the others bits are unused. Modern DAWS support MTC, but can't sync the new video files due to MTC's limitation.
Accepted Answer
0
Undo
Votes
The MMA made a conscious decision not to change any System Message in the first round of new MIDI 2.0 specifications.
But MIDI 2.0 does enable many new possibilities.
Here is a quote from a section of the MMA procedures.
So if you wrote up a formal RFP, and sent it to info@midi.org, we would be happy to circulate the proposal with our MMA members list to seek a sponsor and also bring it to the attention of the Technical Standards Board. This idea has already been discussed during some Protocol Working Group meetings, but again we made a conscious to leave System Messages alone in Phase 1 of MIDI 2.0.
We are a member driven organization and it is our members who volunteer to work on proposals.
But MIDI 2.0 does enable many new possibilities.
Here is a quote from a section of the MMA procedures.
Non-members can't directly participate in MMA discussions, however they may submit proposals for review by obtaining an MMA sponsor, either directly or upon request to the Chairman of the Technical Standards Board.
So if you wrote up a formal RFP, and sent it to info@midi.org, we would be happy to circulate the proposal with our MMA members list to seek a sponsor and also bring it to the attention of the Technical Standards Board. This idea has already been discussed during some Protocol Working Group meetings, but again we made a conscious to leave System Messages alone in Phase 1 of MIDI 2.0.
It is the obligation of the members to consider and, if needed, develop proposals to enhance and improve MIDI technology and establish interoperability of MIDI products.
Any MMA member may initiate a new proposal or topic for discussion by starting a new email thread on the MMA Forum mailing list with an outline of the proposal or discussion, or by having a Technical Standards Board member start it for them. If enough interest is shown by the membership, the topic will be assigned a "TSB Item Number" that is used for identifying all documents and discussions related to the proposal.
We are a member driven organization and it is our members who volunteer to work on proposals.
THE MIDI ASSOCIATION (TMA)
The community of people who work, play and create with MIDI
The community of people who work, play and create with MIDI
Michael B Kent
selected the reply #4865 as the answer for this post — 1 year ago
Accepted Answer
0
Undo
Votes
The MMA made a conscious decision not to change any System Message in the first round of new MIDI 2.0 specifications.
But MIDI 2.0 does enable many new possibilities.
Here is a quote from a section of the MMA procedures.
So if you wrote up a formal RFP, and sent it to info@midi.org, we would be happy to circulate the proposal with our MMA members list to seek a sponsor and also bring it to the attention of the Technical Standards Board. This idea has already been discussed during some Protocol Working Group meetings, but again we made a conscious to leave System Messages alone in Phase 1 of MIDI 2.0.
We are a member driven organization and it is our members who volunteer to work on proposals.
But MIDI 2.0 does enable many new possibilities.
Here is a quote from a section of the MMA procedures.
Non-members can't directly participate in MMA discussions, however they may submit proposals for review by obtaining an MMA sponsor, either directly or upon request to the Chairman of the Technical Standards Board.
So if you wrote up a formal RFP, and sent it to info@midi.org, we would be happy to circulate the proposal with our MMA members list to seek a sponsor and also bring it to the attention of the Technical Standards Board. This idea has already been discussed during some Protocol Working Group meetings, but again we made a conscious to leave System Messages alone in Phase 1 of MIDI 2.0.
It is the obligation of the members to consider and, if needed, develop proposals to enhance and improve MIDI technology and establish interoperability of MIDI products.
Any MMA member may initiate a new proposal or topic for discussion by starting a new email thread on the MMA Forum mailing list with an outline of the proposal or discussion, or by having a Technical Standards Board member start it for them. If enough interest is shown by the membership, the topic will be assigned a "TSB Item Number" that is used for identifying all documents and discussions related to the proposal.
We are a member driven organization and it is our members who volunteer to work on proposals.
THE MIDI ASSOCIATION (TMA)
The community of people who work, play and create with MIDI
The community of people who work, play and create with MIDI
One could send more MTC messages to increase accuracy. Having 60fps or higher the exact frame can be selected. With high USB data rates , the amount of data is not an issue anymore. And old/software/ equipment that ignores bit 6 (it should because minutes and seconds will never go over 59) would not have a problem at all. New Software/Hardware could have a selection to select this high resolution mode to work with older hardware/software. Just like MIDI 2.0 supporting software/hardware may/will have.
0
Undo
Votes
This MIDI specification is about interoperability, so a change like this would make all old software/hardware incompatible.
Anyway, the frame number in MTC messages is only about timing, e.g., for 30 frames/s, a frame number of 15 just means "half a second". The time between two complete MTC messages must be interpolated anyway, so increasing the frame resolution would not necessarily increase the timing accuracy.
Anyway, the frame number in MTC messages is only about timing, e.g., for 30 frames/s, a frame number of 15 just means "half a second". The time between two complete MTC messages must be interpolated anyway, so increasing the frame resolution would not necessarily increase the timing accuracy.
This has absolutely nothing to do with the speed of MIDI. (except that there will be about twice as many MTC messages over the wire)
MTC byte 3, 000fffff: Frame (0–29, or less at lower frame rates)
THUS MTC CAN ONLY SELECT FRAME 0 to 29, NOT BEYOND THAT.
MTC can only address/select these frames
0rrhhhhh: Rate (0–3) and hour (0–23).
rr = 00: 24 frames/s
rr = 01: 25 frames/s
rr = 10: 29.97 frames/s (SMPTE drop-frame timecode)
rr = 11: 30 frames/s
The unused bits in minute and seconds could be used to extend the frame rate bits for "HFR" because the unused bits 6 and 7 in frame# will need to be used for the selected frame (127 max)
One bit could mean to double the frame rate. That is to 48, 50 and 60 and using the seconds bit to go to maximum of 120fps. (The hobbit was shot in 48fps and many MP4 files are in 50fps, and some really high end media goes up to 120fps)
The request for change is thus as follows:
HFR (High Frame rate) support
minute bit 6 - seconds bit 6
0 0 = standard
0 1 = 2x fps (48, 50, 60)
1 0 = 4x fps (96, 100, 120)
1 1 = Not usable because frame maximum is 127
The use case is that software and hardware with MTC can control the playback of video without first having to down convert the video to lower fps rates.
Sure all applications that send and receive MTC will need to be updated. But it's 2017, it's time.
The MMC Locate command will also have to be updated and it has unused bits as well in the frame byte
https://www.smpte.org/atc2012/symposium
https://www.smpte.org/sites/default/files/22-1445-CH6-MASTERING.Mitchell-Wilson-Claydon.pdf
https://en.wikipedia.org/wiki/High_frame_rate
https://en.wikipedia.org/wiki/MIDI_Machine_Control
MTC byte 3, 000fffff: Frame (0–29, or less at lower frame rates)
THUS MTC CAN ONLY SELECT FRAME 0 to 29, NOT BEYOND THAT.
MTC can only address/select these frames
0rrhhhhh: Rate (0–3) and hour (0–23).
rr = 00: 24 frames/s
rr = 01: 25 frames/s
rr = 10: 29.97 frames/s (SMPTE drop-frame timecode)
rr = 11: 30 frames/s
The unused bits in minute and seconds could be used to extend the frame rate bits for "HFR" because the unused bits 6 and 7 in frame# will need to be used for the selected frame (127 max)
One bit could mean to double the frame rate. That is to 48, 50 and 60 and using the seconds bit to go to maximum of 120fps. (The hobbit was shot in 48fps and many MP4 files are in 50fps, and some really high end media goes up to 120fps)
The request for change is thus as follows:
HFR (High Frame rate) support
minute bit 6 - seconds bit 6
0 0 = standard
0 1 = 2x fps (48, 50, 60)
1 0 = 4x fps (96, 100, 120)
1 1 = Not usable because frame maximum is 127
The use case is that software and hardware with MTC can control the playback of video without first having to down convert the video to lower fps rates.
Sure all applications that send and receive MTC will need to be updated. But it's 2017, it's time.
The MMC Locate command will also have to be updated and it has unused bits as well in the frame byte
https://www.smpte.org/atc2012/symposium
https://www.smpte.org/sites/default/files/22-1445-CH6-MASTERING.Mitchell-Wilson-Claydon.pdf
https://en.wikipedia.org/wiki/High_frame_rate
https://en.wikipedia.org/wiki/MIDI_Machine_Control
Is the problem with the MTC Spec?
A quick read via Google suggests that the 30 fps limit is imposed by the SMPTC (?) protocol, not by midi. I'm sure the midi clock/time codes can run at quite enough resolution to handle 60fps? Midi runs at 32k bps (or so). I'd assume that USB emulations of midi could run at even higher rates (and so be capable of higher resolution)?
Geoff
A quick read via Google suggests that the 30 fps limit is imposed by the SMPTC (?) protocol, not by midi. I'm sure the midi clock/time codes can run at quite enough resolution to handle 60fps? Midi runs at 32k bps (or so). I'd assume that USB emulations of midi could run at even higher rates (and so be capable of higher resolution)?
Geoff
- Page :
- 1
There are no replies made for this post yet.
