Sim'n Tonic Forums

To be fair, I don't know if this is a Midronome issue or a Finale bug.
Finale accepts the E-RM sync file but rejects the Midronome sync file.

I just sent the following to Finale support, and I think you'll see what I mean: What is the difference between these files?

The error message is:
Finale cannot place this type of audio file.

In my quest to get external MIDI devices to sync precisely with my Finale scores, I have purchased the new Midronome device.
It is similar to the E-RM Multiclock in that it will follow a special .wav audio stream that it receives from a DAW (in our case, Finale) and in turn generate MIDI sync for downstream devices.

I've tried to load that Midronome .wav file into Finale but receive the error message above.
I even tried the attached minimalistic 2-bar version of the file, 120bpm4_4time2bars48kHz.wav, which is attached.

So as a test, I tried load an actual piece of recorded music, 03 1984.wav, also attached.
This attempt returned the same error message as above.

If it weren't for this second .wav file attempt, I probably wouldn't be contacting you;
because when I attempted to load the E-RM Multiclock sample .wav file, I did not receive the error message, but the Audio Clip Attributes dialog opened just as I expected it to do with the other files.
I've attached this E-RM_multiclock_sample.wav as well.

I have no idea what the difference between the first two audio clips and the third audio clip is.
Finale obviously sees a difference.

Considering Finale claims the ability to load .wav files into an Audio Track and that I very likely will want to do that with a musical passage before long, I would like for you to tell me why 03 1984.wav doesn't work.
In the process, I hope to learn why the Midronome sync track doesn't work while the E-RM track does.

Thank you very much.

NOTE: I would have attached the .wav files mentioned above, but this forum responds with "invalid file extension"

Hi John

Thanks for telling me about this. Let me know what Finale support replies.

I have changed the settings, you should be able to attach wav files now (otherwise put them in a zip).

Cheers
Simon

Thanks Simon,

Finale support replied
I'm able to replicate this issue on my end with these audio files, but I can definitely load other .WAV files into Finale; this makes me curious to explore how these audio file were created. What sample rate are you bouncing these files at? I would recommend bouncing to mp3 at 44.1 kHz and trying that as well.

Well, in the mean time,
I've discovered that I too am able to load other .wav files into the Finale Audio Track.
I also found that when opening a file in Sound Forge Pro, it will give the technical makeup of the file, so I used it to inspect the files in question.

The short musical audio clip was recorded at 48kHz and 24 bits.

The E-RM sample sync waveform - the one that worked - is a 44.1kHz and 16 bits.

The Midronome sync file was generated at 48kHz and, although the bit depth is not specified by Midronome, I found it to be 24 bits.
And, although Midronome gives the option of 48kHz or 44.1kHz, there is no bit depth option.

Sound Forge Pro is able to convert 24 bit to 16 bit.
So, when I generate a Midronome sync clip at 44.1kHz and 24 bits and then convert it to 16 bits, I am able to load it into Finale's Audio Track.


The short answer to my question seems to be that the file must be 44.1kHz and 16 bits.

So, that's a new feature request I suppose. Can we have the option of generating the sync stream in 16 bits?

I did run into other, probably non-Midronome, quandaries while testing but will try to catch up on this forum's recent entries before tapping yet again into your fountain of knowledge and beneficence.

Thanks, and best regards,
John

Yes there are 24 bits, I just assumed this was standard since any modern DAW will work in 24 bits.
I guess Finale is not really a DAW, more of a score editor, hence the requirement for 16-bits.

Yes, while it is substantially more than a score editor, I do seem to have a knack for bumping into its limitations.

Glad to hear adding 16 bits is not a big deal. I'm looking forward to it!

Thank you, Simon.