I can probably open this for you later using some help from a Lua script I made.
Been working on it now, but just need more time it seems (-it depends on how many corrupted files/regions there are).
I have something else I need to do right now though, so I’ll try to get back to this in a few hours.
-J
You reported this several months ago and a couple of users made suggestions which apparently fixed it (it looks like something is corrupting your midi files):-
Session not loading due to error - Installation & Configuration / Windows - Ardour
I checked from the archive on dropbox, and file just indicates it is binary data:
$ file ‘LABS 1-39.mid’
LABS 1-39.mid: data
It appears to be all nul bytes:
$ xxd ‘LABS 1-39.mid’
00000000: 0000 0000 0000 0000 0000 0000 0000 0000 …
00000010: 0000 0000 0000 0000 0000 0000 0000 0000 …
00000020: 0000 0000 0000 0000 0000 0000 0000 0000 …
00000030: 0000 0000 0000 0000 0000 0000 0000 0000 …
etc. to the end, identical bytes.
The file has a name like it was created by Ardour as MIDI data for a track, but it doesn’t even have a header chunk.
There are not just a few:
$ find ./ -name *.mid -print0 | xargs -0 file | grep -v “Standard MIDI” | wc -l
153
153 files with .mid extensions which are not actually SMF format files.
There are however 452 .mid files which are detected as “Standard MIDI data (format 0).”
There does not seem to be a simple pattern to the bad files.
I looked at some example files near the end of the list, and for example there are a large number of files with names beginning with Take1_Drums that are not valid, but interspersed in the middle of other files with similar names which are.
Take1_Drums-24.mid and Take1_Drums-26.mid are not valid, but Take1_Drums-20.mid through Take1_Drums-23.mid are valid, and Take1_Drums-25.mid is valid.
I do not recall hearing anyone report this same symptom before.
I was using this script here to manually delete corrupted/problematic midi regions from your main XML (.ardour) file itself. But if there really are 153 problematic sources/files as @ccaudle says there is (which seems likely), then this process would take way too long for me (or anyone) to delete them one-by-one.
Hopefully some other solution will work for you though!
-J
I wonder if there is some sort of faulty file sync operation going on on the OP’s PC which is corrupting files.
Cheers,
Keith
Your Zipfile seems seriously garbled, it contains another zip with the same name but very different content… and the session from the “outer” zip refuses to load for me, actually I have to xkill ardour8 because it freezes and doesn’t even react to killall -9. Loading the session via “Midsummer’s Night Dream.ardour” from the unzipped “inner” zip works for me on Linux, but I miss some of the plugins you use. So, I don’t think the session in the inner zip is corrupted.
Here’s the terminal output for this run:
LANG=C ardour8 Midsummer\'s\ Night\ Dream.ardour
Ardour8.12.0 (built using 8.12 and GCC version 15.1.1 20250801)
Ardour: [INFO]: Your system is configured to limit Ardour to 524288 open files
Ardour: [INFO]: Loading system configuration file /etc/ardour8/system_config
Ardour: [INFO]: Loading user configuration file /home/ed/.config/ardour8/config
Ardour: [INFO]: CPU vendor: AuthenticAMD
Ardour: [INFO]: AVX capable processor
Ardour: [INFO]: AVX with FMA capable processor
Ardour: [INFO]: CPU brand: AMD Ryzen 7 5700U with Radeon Graphics
Ardour: [INFO]: Using AVX and FMA optimized routines
Ardour: [INFO]: Set CPU DMA latency to 0 usec
Ardour: [INFO]: Loading plugin meta data file /usr/share/ardour8/plugin_metadata/plugin_tags
Ardour: [INFO]: Loading plugin statistics file /home/ed/.config/ardour8/plugin_metadata/plugin_stats
Ardour: [INFO]: add_lrdf_data '/home/ed/.config/ardour8/rdf:/usr/share/ardour8/rdf:/usr/local/share/ladspa/rdf:/usr/share/ladspa/rdf'
Ardour: [INFO]: read rdf_file 'file:///usr/share/ladspa/rdf/cmt.rdf'
Ardour: [INFO]: read rdf_file 'file:///usr/share/ladspa/rdf/blop.rdf'
Ardour: [INFO]: read rdf_file 'file:///usr/share/ladspa/rdf/swh-aux.rdf'
Ardour: [INFO]: read rdf_file 'file:///usr/share/ladspa/rdf/swh-plugins.rdf'
Ardour: [INFO]: read rdf_file 'file:///usr/share/ladspa/rdf/swh-scales.rdf'
Ardour: [INFO]: read rdf_file 'file:///usr/share/ladspa/rdf/tap-plugins.rdf'
Ardour: [INFO]: read rdf_file 'file:///usr/share/ladspa/rdf/tap_reverb.rdf'
Ardour: [INFO]: read rdf_file 'file:///usr/share/ladspa/rdf/ladspa.rdfs'
Ardour: [INFO]: read rdf_file 'file:///usr/share/ladspa/rdf/ladspa-rubberband.rdf'
Ardour: [INFO]: Loading default ui configuration file /etc/ardour8/default_ui_config
Ardour: [INFO]: Loading user ui configuration file /home/ed/.config/ardour8/ui_config
Ardour: [INFO]: Loading 461 MIDI patches from /usr/share/ardour8/patchfiles
Ardour: [INFO]: Loading color file /usr/share/ardour8/themes/xcolors-ardour.colors
Ardour: [INFO]: Loading ui configuration file /etc/ardour8/clearlooks.rc
Ardour: [INFO]: Loading bindings from /etc/ardour8/ardour.keys
Loading ui configuration file /etc/ardour8/clearlooks.rc
lilv_plugin_load_ports_if_necessary(): error: Plugin <file:///usr/lib64/lv2/ingen.lv2/MonoInstrument.ttl> is missing port 2/4
lilv_plugin_load_ports_if_necessary(): error: Plugin <file:///usr/lib64/lv2/ingen.lv2/StereoInstrument.ttl> is missing port 2/6
Thank you I really appreciate this, so just to make sure my files won’t get corrupted or misplaced where do I save this inner zip file within the session folder. As in to replace since the session I wanted to fix is corrupted.
The inner zip is a session archive from end of may, it seems.
In the session dir you worked with yesterday, rename or copy “Joke’s On You.pending” to “Joke’s On You.ardour” and Ardour will be able to open that snapshot (for me it does). For the main session (trying to load that as snapshot from the right side panel tab) I get the corrupted message and ardour stalls. I don’t have the skills to fix that, so hopefully @x42 or @paul can…
I replied in the original post, since that is where Paul had originally replied.
The problem is that there are 153 files which end with .mid, but which are not actually valid MIDI data files.
There are a total of 452 mid files which are detected as valid MIDI files, meaning that at least the beginning of the data is correct.
The mid files which are not valid MIDI data are all 00 values. I looked at some example files near the end of the list, and for example there are a large number of files with names beginning with Take1_Drums that are not valid, but interspersed in the middle of other files with similar names which are.
For example Take1_Drums-24.mid and Take1_Drums-26.mid are not valid, but Take1_Drums-20.mid through Take1_Drums-23.mid are valid, and Take1_Drums-25.mid is valid.
I don’t recall seeing any other problem descriptions like this, so I don’t think anyone can tell you yet how to prevent it from happening in the future.
Do you have any software running which might occasionally lock the directory in use, for example OneDrive or similar cloud backup service? That can sometimes cause problems (although I have not seen anyone report this exact symptom, so I admit that is just guessing at this point).
Actually that is exactly a potential behavior I would expect out of say OneDrive if you are running the local client and tell it to manage the files saved on your computer. It puts in empty ‘stubs’ to represent the file in the cloud on your filesystem and downloads the file on demand typically, which has caused issues in other software. iCloud I know is a similar issue, and I would be surprised if Google Drive doesn’t also run into it for instance.
This is part of (But in no way the only reason) I tell people to be VERY cautious about using the cloud sync services for things like this. Filename/case mangling is another very real reason.
Seablade
FYI Merged in a second thread on the same topic, no need to create a new one, we are already in the Windows topic
Thank you and everyone else for getting back to me, sorry I took awhile to respond. I will go through each of your comments and see if I can recover the session.
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.