Formal file translation and modermization requests

[geezer]

Alright-

In response to the admin request in another thread, I will, once again, talk about some simple and very limited steps needed to continue to use Microeditor in the modern environment.....I would like to note that none of the questions I am raising are new. All statements can be found in threads from at least 2 to 3 years ago, and probably a bit further back than that.

However, since we have the admin's attention, I am going to state my particular views on the subject, and ask for others to chime in after me.

Since the admin is raising the issue of cost, I will arrange the solutions below in order of cost (least to most, in my opinion), and will indicate why I think at least 2 of the solutions should be very inexpensive......

File sharing, which is all I am really talking about, has always been my approach to low-cost compatability for MTU, in the face of zero money for serious feature development.

FILE SHARING SOLUTIONS:

1)32 BIT FILE SHARING (virtually free from cost)- It is my understanding that most other, modern native programs will open an .SF file as a "raw" 32bit floating point file......This is a done deal. These programs alll work natively in this format, and will save in this format. All that needs to happen now is to nail down what has to be done in the file header to bring it back into Microeditor.....Kind of a no-brainer, eh?

2)24 BIT WAV FILE SUPPORT (fairly low cost, I would think)....I don't think it should be hard to figure out the specs for these, either. Allowing Microeditor to read and write 24 bit Wav files would make it instantly compatible with everything else.

3)BROADCAST WAV FILE SUPPORT (don't understand how hard the programming, and thus the cost, for this would be)- This could happen on at least 2 different levels: a)simple recognition and use of files without using (or losing) any of the embedded (i.e.- time code) data. b)implentation of the time code data in time coded projects.........I put in a good amount of time to send MTU some BroadcastWav files 2 years ago, with no response. I don't know what that means.


.....All 3 of these solutions above involve code that is already existent to some extent in MTU. None of them address the other issue that I don't see MTU ever addressing: higher sampling rates.....this is the long term compatability issue, but, even though I have begun working at 96k, I don't think it will be deadly for MTU for another 4 years or so.

Anyway, feel free to chime in.

[Allen Brown]

geezer -

I support you in your effort to get some action going on ME future dev. If I read the admin post correctly, it all hinges on our willingness to pay for same.

I am unable, at this time, to contribute to the technical discussion. I will say, however, that I would be willing to pay to see this machine and this way of working survive into the future.

I know that doesn't help much. I'm just expressing my interest to help keep the discussion alive. I hope the exasperation others have felt over the past few years won't keep them from commenting constructively on this.

File sharing compatiblity seems like a good place to start.

Allen Brown

[mlepine]

Quote from geezer:

2)24 BIT WAV FILE SUPPORT (fairly low cost, I would think)....I don't think it should be hard to figure out the specs for these, either. Allowing Microeditor to read and write 24 bit Wav files would make it instantly compatible with everything else.

Once you experience the 24 bit sound it's very hard to go back to the standard 16 bit 44K. With the new DVD market it should be a priority to have this technology into the MTU product.
Windows Media Player & the Creative Media Source plays the 24 bit.

Regards

[geezer]

.....Of course, MTU already supports 24bit files via Krystal, but they are proprietary.
All the .wav reading and generating software in Medit are pre-Krystal and only support 16 bit files.

As I have said above, it seems likely to me that upgrading this portion of Medit (.wav read and write) would be one of the least costly upgrades possible, though not as simple as providing us with the header data needed for the native .SF 32 bit files.