Problems with capella files

• Jan 14, 2012 - 15:22
Type
Functional
Severity
S2 - Critical
Status
closed
Project

When you open capella files with museScore you will encounter several issues. So far I have encountered three.

If you have created a system of, say, soprano-alto-tenor-bass, with capella and you open the file with museScore, the notes of the tenor line are all transposed up one octave compared to the original although museScore shows the right key.

In addition, it is impossible to create a "Start repeat" at the beginning of a system. The line is only shown in the first line of the system. If the file was created with museScore from scratch there is no problem at all.

Also, museScore don't recognizes the number of lines a system has when the piece of music was created first with capella. You will clearly see this when you use the mixer (F10) with the attached example.
If you use museScore from scratch you can use the mixer and all parts of the piece are shown correctly. So you can mute certain parts of the file.

Attachment Size
Example.mscz 8.09 KB

Comments

Hi there,

first of all, capella is capable of exporting cap-files as xml.
Attached you will find a xml-file which was created by using the export function of capella and the corresponding cap-file as a zip-file. Otherwise I could not have uploaded it.

To me it seems as if museScore is capable of treating only the xml-file correctly.

I use Windows XP, SP 3 and capella 2008.

Attachment Size
Example xml-file.xml 217 KB
Example capella-file.zip 2.65 KB

I've just found a bunch of files that crash on import in a recent nightly build, cbd68b8
They all start with a start repeat bar line, this seems to be the common denominator and cause of the crash

gizzmo456's .cap file though now seems to import without crashing, but still has the transpose/octave as well as the multi-sfaff problem.

Do we need to split this issue into several?
a) importing tenor staff one octave to high
b) capella import doesn't recognize number of sfaffes per system and creates one multi staff instrument instead.
c) crash on capells import, if that begins with a start repeat (regression vs. 1.x)

Problem with that: I don't have Capella, just read only versions (Reader and Demo). But lots of Capella files that fail, though I can't really share them, due to copyright.

f) ties and slurs get lost

I'll try to get some sample files, if and when I do, I'll create separate issues for each

Links to failing files on public download sites such as hausmusik.ch would help too, although smaller files that demonstrate issues make debugging easier.

I don't have Capella either. I did download and import a number of capx files from hausmusik into MuseScore, but did not find any crashes.

The very fist score on hausmusik.ch I looked at (//www.hausmusik.ch/notenregal/a/aguado_dionisio(1788-1847)/tanz_d-dur/ ) shows the wrong octave problem, when importing the .cap file. The .capx doesn't have that issue (but others, I guess known restrictions, no slurs for example)

Another one (//www.hausmusik.ch/notenregal/a/ahle_johann-rudolf(1625-1673)/jesu_meines_%20herzens_%20freud/ ) show the losing ties problem (no .capx here). Other ties (from some other scores) have got imported though.

Same score also shows the lose end bar problem.

Another one (//www.hausmusik.ch/notenregal/z/zelter/chor/bundeslied/ ) shows the single instrument with multiple staves problem in both cap and capx import as well as the wrong octave problem in cap import, the lose end bar and the lose tie problem. Fermatas are lost too, as is the title.

All in all I wouldn't really call this 'imports Capella files fairly accuratly' like the handbook claims.... esp. as 1.x import is even worse.

Voltas are lost too

Some small files to illustrate the problems described above (created with Capella 7). Note that Capx import is different from Cap import for the number of beats in the first measure.

Attachment Size
Capella.zip 22.84 KB

Hmm, tie.cap works in 1.3 and 6d6d73d, so my report was wrong. Guess in the cap file I imported they really were slurs but should have been ties.
slur.cap works in 1.3 but not in 6d6d73d, so it is a regression.

other than that, yes, these show the behavoir I described.

SATB shows an additional problem with several vertical frames, 2 containing nothing but a #. Strangly with 1.3 vs. 6d6d73d in a different order.

Status (old) active duplicate

Will close this issue with status "duplicate", as separate issues now have been submitted for the various problems, and no commit in GitHub refers to (or will refer to) issue 14438.