fbpx
Skip to main content

MIDI Forum

The MTC standard an...
 
Notifications
Clear all

The MTC standard and beyond 30fps support

7 Posts
4 Users
0 Reactions
18.2 K Views
Muzak
Posts: 82
Estimable Member
Topic starter
 

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.

 
Posted : 17/09/2017 7:51 am
Geoff
Posts: 1039
Noble Member
 

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

 
Posted : 17/09/2017 9:15 am
Muzak
Posts: 82
Estimable Member
Topic starter
 

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

 
Posted : 17/09/2017 10:24 pm
Muzak
Posts: 82
Estimable Member
Topic starter
 

After more than 2 years no further comments and ideas to use the unused bit 6 in minute and seconds ? Can do a formal RFP to MIDI.ORG if needed. where to submit to ?

 
Posted : 18/02/2020 11:32 pm
Clemens Ladisch
Posts: 321
Reputable Member
 

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.

 
Posted : 19/02/2020 5:05 am
Muzak
Posts: 82
Estimable Member
Topic starter
 

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.

 
Posted : 19/02/2020 8:26 pm
The MIDI Association
Posts: 100
Admin Registered
 

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.

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.

 
Posted : 05/03/2020 10:18 am
Share: