MP3 Export Length 3secs too long
Operating system is Windows 7 Professional 64 bit. MuseScore version is 2.0.3, Revision 3c7a69d.
I've got a score with the tempo marking as quarter note = 60, AND the Follow Text control is checked AND the grayed-out Tempo control is showing 60.0BPM AND the Play Panel has been reset to 100% after temporarily setting down to 10% to ensure 100% is active setting. With the Play Panel tempo at 100%, the score is shown to be exactly 2:12 in duration but the mp3 is 2:15 in duration. So are the exported FLAC, OGG & WAV files. Exporting all four types and importing all four outputs into Audacity shows the four exported audio files are apparently identical.
The score was a project to write a bass line to match a play-along file, also 2:12 and exactly 60bpm.
I also tried using Windows Task Manager to set the priority of the MuseScore task to high to ensure it had all the cpu cycles needed during export; but that made no difference.
The properties of my 704kb lame_enc.dll shows product name L.A.M.E., product version 3.99 release 5, and file version 3.99.2.5
I'm also failing in my rookie attempts to sync via Audacity the MuseScore-exported mp3 and the play-along mp3 files.
Can someone offer a solution as to how to correct the duration of the exported mp3 file?
I've attached the score but could not attach the mp3.
Thank you!
Tim Patton, Houston, TX, USA
Attachment | Size |
---|---|
Sept 2016 BLC My Bass Line.mscz | 38.33 KB |
Comments
It's normal for there to be a little padding at the end of an audio file generated from MIDI, because many MIDI sounds decay for longer then the stated value. Imagine, for instance, a piece on which a cymbal is crashed on the last beat. Or, there mnight be reverb applied that causes the sound to still decay a little while even for other instruments. If the audio cut off right at the final bar, these natural sounds would be cut off.
If for some reason you need your audio file trimmed and you don't mind losing that final decay, you can simply edit it in Audacity.
As for syncing, what did you try? In theory this should be possible via JACK and/or OSC, but I'm totally out of my element here. At least I gave you two acronyms to search for if you aren't familiar with then, though.
In reply to It's normal for there to be a by Marc Sabatella
Thank you so much for your reply, Marc!
The problem wasn't the extra padding, but that the tempo was incorrect. I found a work-around but still think there is a bug that my work-around merely bypassed.
Here are two aspects about the file that I did not mention because they were aspects of earlier edits and had been discarded and the score saved: in a much earlier version, the score once had a 1/16 pickup measure and later had a 1/16 final measure. Both measures were deleted days ago, but perhaps a ghost of either of them was present in the mp3. My work-around - purely trial and error - was that I added a single empty 4/4 measure to the end. That kicked the time to 2:16, which was fine because I don't care about the extra four seconds. The crucial change was that the actual music duration was "fixed" to 2:12, as required; and the tempo was then correct so that the mp3 synced automatically with the play along file.
In reply to Thank you so much for your by Tim.Patton
I don't understand the bug you mention. What makes you think the tempo is off? The difference in length would be for the reason I explained. Can you give precise steps ROI reproduce the problem your are perceiving?
In reply to I don't understand the bug by Marc Sabatella
Thank you, Marc. I apologize for being unclear. I attached the MuseScore file, but did not attach the 60BPM audio track I was syncing it with, so you would have been unable to test my results.
I suspect you MAY, however, reproduce them.
(1) From the file I attached, export an audio file.
(2) Append one empty 4/4 measure.
(3) Export a second audio file.
(4) Import the two outputs together into Audacity (or comparable analysis tool) and scrutinize how the two tracks align.
When I say the tempo is off - again, in the mp3 output of the file I attached, not in the mp3 output of the file that has my extraneous appended measure - I am saying that, though every possible means (Play Panel, tempo marking and tempo bypass) were used to ensure 60BPM in the exported MP3, the resultant file was not 60BPM, but stretched, to such an extent that I could not sync it to the 60BPM audio file.
Specifically, 33 measures of 4/4 at a tempo of 60BPM (1 beat per second) should produce 2:12 of audio (33*4=132 seconds.) And indeed, after my workaround of appending an empty 4/4 measure, 34 measures did produce 2:16 of audio (34*4=136.) When I say the tempo was off, I mean that the resultant tempo from the file I attached was not 132 beats over a span of 132 seconds at 1 second per beat, but rather 132 beats across 135 seconds, or 1.02273 seconds per beat, or stated inversely, 0.9778 beats per second. Apart from a hearing with the ear, a seeing with the eye* can be found in comparing the incorrect duration of the audio exported from the file I attached with the correct duration of audio exported after my workaround is applied.
My workaround eliminated the symptom of the now-hidden-again error. At this point, my guess is that adding the measure solved the problem by forcing a recalculation of the tempo, duration and total number of beats among all the program variables holding such values. I speculate that the variable data used to ensure midi playback and the same variable data used to export audio are allowed by some execution path to become inconsistent; i.e. that some variable(s) were correctly updated when the 1/16 measure was deleted earlier, and some other variable(s) missed that update. I speculate that, at a minimum, some mathematical aspect of the deletion of the 1/16 measure at the end and the result that deletion should have had on overall statistics of the audio export somehow failed to carry over to whatever relevant software section governs the duration and tempo of exported audio. (Remember that the error existed in the OGG, FLAC, and WAV files, as well.) Whether the failed path lies in the deletion of a measure at the end, or the detection of the deleted measure being not a 1/4 measure, but a 1/16 measure, I could not know. I'm only speculating that the software error is related to that measure being somehow a ghost in the machine. It might lie somewhere else, perhaps in updates generated by the Play Panel or the tempo Inspector. Perhaps it's just a fluke.
Please let me know if I've failed again to answer the question you intended. If this answer still does not satisfy, please be assured that I am trying to be cooperative and am just being inept at it.
Thank you, Marc.
*Job 42:5
In reply to It's normal for there to be a by Marc Sabatella
Thanks for you response, but I have 42 channels with 3 seconds long... cutting them in audacity is a bit tedious, any alternatives?
In reply to Thanks for you response, but… by awsapps
By "channels" do you mean "files"? The number of MIDI channels in a single file should be irrelevant, it would still take only a single operation. But presumably Audacity supports some sort of automation to trim the ends of files in a batch.
In reply to Thanks for you response, but… by awsapps
If you've imported them all into Audacity, then cutting off their ends is just a single action.