Batch conversion silently fails (and buggy MSCX conversion)

[ThePython10110]

Issue type

Import/export issue

Bug description

Attempting to run a batch convert does absolutely nothing. It must have at some point, because I have converted files in MS4 previously, but not anymore. The JSON file is formatted correctly, and there is no error code. There's no way I can find to get any kind of debug information (-d/--debug doesn't work).

Fortunately, I was generating the JSON file with a Python script, so I just skipped the JSON and made my script convert every file individually with -o. This led me to another issue: Converting to .mscx files randomly fails sometimes. Retrying the conversion (sometimes multiple times) seems to work. It's not VST related, since it happened to a score that didn't have VST's (unless the built-in reverb counts). It doesn't happen with MP3, MIDI, PDF, MXL, or MusicXML file types (I haven't tested any others). It does seem to depend on the score, since some seem to fail most of the time, and some never fail. It doesn't seem to matter which instruments the score includes (one score only had guitar, and one only had piano and strings).

Steps to reproduce

Batch convert issue

1. Create a batch convert JSON file.
2. Run <path to MuseScore4.exe> -j <path to JSON file>
3. Silently fails.

Other conversion issue

1. Try to convert a whole bunch of files
2. About a third (?) will fail to convert to .mscx

Screenshots/Screen recordings

No response

MuseScore Version

4.3.2

Regression

Yes, this used to work in a previous version of MuseScore 4.x

Operating system

OS: Windows 10 Version 2009, Arch.: x86_64

Additional context

No response

[bemain]

How do you generate parts individually using -o? Or maybe you don't do that?

[pacebes]

It does seem to depend on the score, since some seem to fail most of the time, and some never fail. It doesn't seem to matter which instruments the score includes (one score only had guitar, and one only had piano and strings).

Could you provide us with a score that fails most of the time and the json ??

[jmh-git]

I have a similar issue and believe the batch conversion silently fails as I get no output at all. I am using a MacBook Air and the version MuseScore: Music Score Editor; Version 4.4.4; Build 2232670.

Here is how I invoke MS4:

mscore -j MyScore_export.json

mscore is in the PATH. The program produces 40 messages of the form:

qt.qml.typeregistration: Invalid QML element name "IconCode"; value type names should begin with a lowercase letter

In addition to "IconCode", other elements such as "MusicalSymbolCode" or "ContainerType" are flagged. The text doesn't look like it is an error when it says ... should begin with a lowercase letter. So I assume it is unrelated to this issue.

When I try to add the option --diagnostic-output <output> there is no difference. For <output> I gave the name of a .txt file. But nothing is produced.

The conversion file MyScore_export.json looks like this. I used the same format in MS3 without problems on a Windows laptop. So I assume it is still correct. This file is generated by a Python script depending on the name of the .mscz scorefile.

[
    {
        "in": "MyScore.mscz",
        "out": [
            [ "MyScore_",".mp3"],
            "MyScore_Tutti.mp3"
        ]
    }
]

No output is written to the syslog. Happy to do more tracing if someone could tell me how to enable it. As noted above in a previous comment, the -d switch didn't make a difference.

[williamszostak]

I'm having the same issue with MuseScore 4.4.4.
It doesn't work when the "out" object is an array.

This works:

[
    {
        "in": "MyScore.mscx",
        "out": "MyScore.pdf"
    }
]

(The above produces the same "Invalid QML" messages that @jmh-git mentioned above, but it successfully produces the pdf file.)

This also works:

[
    {
        "in": "MyScore.mscx",
        "out": "MyScore.musicxml"
    }
]

(same as above)

But this does not work:

[
    {
        "in": "MyScore.mscx",
        "out": [
            "MyScore.pdf",
            "MyScore.musicxml"
        ]
    }
]

As others have noted, it fails silently (apart from the same "Invalid QML" messages that are also produced when it succeeds). In linux, the exit code is 0. But it doesn't produce any output file.

Crucially for what I'm trying to do, this also doesn't work:

[
    {
        "in": "MyScore.mscx",
        "out": [
            [
                "MyScore-",
                ".pdf"
            ]
        ]
    }
]

This also exits with 0, gives no error messages, but produces no output files.

As @ThePython10110 noted in the Bug Description, you can work around using an array of output files (if you're not trying to export individual parts), by just using the -o option multiple times.

But as @bemain 's question implies, there is no such work-around for exporting the individual parts. (At least as far as I know. If anyone has a solution, I'd love to hear about it!)

[williamszostak]

Interestingly, it also doesn't work if out is an array with just a single filename.
For example, this doesn't work:

[
    {
        "in": "MyScore.mscx",
        "out": [
            "MyScore.pdf"
        ]
    }
]

Even though this works:

[
    {
        "in": "MyScore.mscx",
        "out": "MyScore.pdf"
    }
]

So it seems that it's not about the number of output files, but about the fact that it's an array.

[pacebes]

I have a patch that makes this syntax work:

[
    {
        "in": "MyScore.mscx",
        "out": [
            "MyScore.pdf"
        ]
    }
]

And also this one:

[
    {
        "in": "MyScore.mscx",
        "out": [
            "MyScore1.pdf",
            "MyScore2.pdf"
        ]
    }
]

So, if this is the issue I can create the pull request to accept this syntax.

[pacebes]

I have created a pull request to allow an array of output files such as:

[
    {
        "in":"Score_23458.mscz",
	     "out":[
			"Score_23458_4.mp3",
			"Score_23458_1.pdf",
			"Score_23458_2.pdf",
			"Score_23458_3.pdf"
			]
    }
]

I expect this solves the initial problem

[pacebes]

By creating this PR ( #26229) I have discovered a way to make MuseScore crash always. Example set of files: Score_23458_alwasyfails.zip

If you uncompress the zip:

• Never fails command: MuseScore4.exe -j Score_23458_neverfails.json -d
• Always fails command: MuseScore4.exe -j Score_23458_alwaysfails.json -d

You have to run it with this PR applied, but I double checked and it doesn't seem to have nothing in common with the PR itself.

Sorry to bother @cbjeukendrup , but I don't know how to report it because I can only crash the program with this PR applied. Sorry to repeat myself, but I think the problem isn't in the PR itself. Could you please check it?. Last log files:

2025-01-24T17:54:10.951 | INFO  | 26144           | MuseSamplerWrapper::initSampler | Successfully initialized sampler, sampleRate: 44100, blockSize: 1024
2025-01-24T17:54:11.024 | DEBUG | 26144           | FluidSynth::init | synth inited

2025-01-24T17:54:11.024 | ERROR | 26144           | FluidSynth      | INFO chunk size mismatch
2025-01-24T17:54:11.050 | INFO  | 26144           | FluidSynth::addSoundFonts | success load soundfont: C:/d/MS_TSIG/builds/Win-Qt6.2.4-msvc2019_64-VS17-RelWithDebInfo/install/sound/MS Basic.sf3
2025-01-24T17:54:11.079 | INFO  | 26144           | FluidSynth::addSoundFonts | success load soundfont: C:/d/MS_TSIG/builds/Win-Qt6.2.4-msvc2019_64-VS17-RelWithDebInfo/install/sound/MS Basic.sf3
2025-01-24T17:54:11.080 | DEBUG | 26144           | FluidSynth      | Selected preset 'Standard' on channel 0

I have tried to find where the problem is but this seems a bit complex to me and I would like to focus on other issues. Anyway, if you consider that I could also try to fix it let me know

[cbjeukendrup]

@pacebes Indeed it seems almost certain that this crash is not caused by a mistake in your code. That always gives us a bit of a dilemma: should we merge code that is fine in itself, but exposes a bug?

I will look into this case when I can, but I am quite busy the coming week.

[pacebes]

@pacebes Indeed it seems almost certain that this crash is not caused by a mistake in your code. That always gives us a bit of a dilemma: should we merge code that is fine in itself, but exposes a bug?

I have seen that the bug is already exposed without this code. I have found a simple way to get a crash when you create a bunch of tasks this way (already supported without this code):

[
    {
        "in":"Score_23458.mscz",
	     "out":"Score_23458_1.pdf"	
    },
    {
        "in":"Score_23458.mscz",
	     "out":"Score_23458_2.pdf"	
    },
     {
        "in":"Score_23458.mscz",
	     "out":"Score_23458_3.pdf"	
    },
     {
        "in":"Score_23458.mscz",
	     "out":"Score_23458_3.mp3"	
    }
 ]

You always get a crash. I have created the issue: #26237

I will look into this case when I can, but I am quite busy the coming week.

Thanks for the info.