Request for Comments: Deprecation of MUS and SIB files

Moderator: kcleung

Should MUS and SIB files be deprecated?

Yes
10
43%
No
10
43%
No opinion
3
13%
 
Total votes: 23

daphnis
Copyright Reviewer
Posts: 1634
Joined: Thu May 17, 2007 7:15 pm
notabot: 42
notabot2: Human

Re: Request for Comments: Deprecation of MUS and SIB files

Post by daphnis »

As mentioned before, even the largest of typesets weigh-in at less than 200KB (with no embedded audio), so if someone wanted to download a PDF of the typeset score, tacking on another 80KB on average wouldn't really make that much difference.
vinteuil
Groundskeeper
Posts: 1445
Joined: Sun Oct 05, 2008 3:01 pm
notabot: YES
notabot2: Bot
Location: U.S.A.
Contact:

Re: Request for Comments: Deprecation of MUS and SIB files

Post by vinteuil »

At 56 KB/s (dialup) it does...
Formerly known as "perlnerd666"
Yagan Kiely
Site Admin
Posts: 1139
Joined: Sun Jan 14, 2007 8:16 am
notabot: YES
notabot2: Bot
Location: Perth, Australia
Contact:

Re: Request for Comments: Deprecation of MUS and SIB files

Post by Yagan Kiely »

What is the (likely) percentage of dial-up users? I know of no-one (personally or otherwise) that still uses dial-up.
imslp
Site Admin
Posts: 1642
Joined: Thu Jan 01, 1970 12:00 am

Re: Request for Comments: Deprecation of MUS and SIB files

Post by imslp »

I see that this is a rather contentious issue. I won't do anything (or rather, I'll fix the MUS/SIB blocking bug) this upcoming maintenance (in ~1 hour). I'll keep the poll and discussion open, since we still have some time before I leave.

It may be because of me being a programmer, but I would personally perfer simplicity over whatever small gains splitting out the typeset is going to have. I'm not the biggest fan of Apple (nor do I use Apple computers), but I do think their idea of simplicity works well for the end user.

It also eases maintenance, and especially my suspicion of the two closed and untested formats. To be honest, I'm slightly wary of distributing random MUS/SIB files, sort of like when I deprecated ZIP files after I found someone uploading a ZIP of some unknown EXE file. There haven't been similar problems, but I think standardizing to PDF is a good step to take, especially since IMSLP will likely grow in reach and traffic. Of course this doesn't protect PDF attachments, but those should only be used in specific circumstances, and it should be the responsibility of the user to understand the potential implications of such (like, really, every other file on the Internet).

But that's just my personal opinion as another IMSLP contributor. I will leave this matter up to the community.
coulonnus
active poster
Posts: 1530
Joined: Thu Jul 12, 2007 8:53 am
notabot: 42
notabot2: Human
Location: Nice, France
Contact:

Re: Request for Comments: Deprecation of MUS and SIB files

Post by coulonnus »

Yagan Kiely wrote:I see absolutely no point in having these files.
At WIMA the habit is to post the MusiXTeX or PMX source along with the .pdf of each score. This because if you are new to either typesetting software and find a score with something you haven't yet learnt how to typeset you can open the source code with your favorite text editor and learn from it, because both softwares are in command-line modes, not WYSIWIG.

Can one learn from a .MUS, a .SIB file? I'm curious!
Yagan Kiely
Site Admin
Posts: 1139
Joined: Sun Jan 14, 2007 8:16 am
notabot: YES
notabot2: Bot
Location: Perth, Australia
Contact:

Re: Request for Comments: Deprecation of MUS and SIB files

Post by Yagan Kiely »

It doesn't tell you which sub-menu the item is from, if that's what you mean.

I understand that their are situations where having the source should almost be a requirement, but I don't believe IMSLP is one of those cases. We aren't an educational source on typesetting, and I don't see any point in becoming one. Specialising on scores mean that we are good at what we do, I don't think it a good idea to spread our selves to thin and be a jack-of-all-trades.
musicxml
Posts: 3
Joined: Mon Aug 03, 2009 10:45 pm
notabot: 42
notabot2: Human

Re: Request for Comments: Deprecation of MUS and SIB files

Post by musicxml »

MusicXML would make a good choice for a standard music source format. But you will want to use the compressed MusicXML (.mxl) format introduced with MusicXML 2.0, not the uncompressed .xml files. Compressed .mxl files are roughly the same size as the corresponding MIDI or source .mus/.sib files, but uncompressed MusicXML files are indeed much larger.

Over 100 applications support the MusicXML format to some extent, as listed at http://www.recordare.com/xml/software.html. MusicXML 2.0 preserves formatting as well as music. The Finale products all support MusicxML, with even NotePad and Reader supporting the MusicXML 2.0 format in their 2009 releases.

If IMSLP wants to distribute source files, then having one standard format should be easier for both users and IMSLP maintainer alike, compared to a potentially endless variety of source file formats.

While .mxl files are .zip files, one could do validation of the .mxl file before posting to make sure the contents of the zip are MusicXML files, not a .exe of something else sinister.

More information on MusicXML is available at http://www.recordare.com/xml.html and through the MusicXML developer e-mail list at http://www.recordare.com/lists#MusicXML.

Best regards,
Michael
Yagan Kiely
Site Admin
Posts: 1139
Joined: Sun Jan 14, 2007 8:16 am
notabot: YES
notabot2: Bot
Location: Perth, Australia
Contact:

Re: Request for Comments: Deprecation of MUS and SIB files

Post by Yagan Kiely »

I would support MusicXML over all other formats. But I still don't see that much of a point.
lpd
Posts: 2
Joined: Wed Feb 03, 2010 4:56 pm
notabot: 42
notabot2: Human

Re: Request for Comments: Deprecation of MUS and SIB files

Post by lpd »

Michael Good, the designer of MusicXML, recently said in a user's forum:

"Music notation is very complex, so one key way we simplified MusicXML is to have it primarily model a document - a musical score or part - rather than an abstraction of a document. MusicXML models what is on the printed page, using musical semantics that also models performance information about that music."

In other words, MusicXML deliberately omits semantic information about the music in order to achieve greater commonality. In terms of semantic level, this puts it somewhere in the middle between Finale and Sibelius (which attempt to encode ever-increasing amounts of the semantics in order to be more valuable to composers) and PDF (which encodes almost none of the semantics, other than by using font symbols rather than graphics).

In short, Finale / Sibelius, MusicXML, and PDF are solving different problems.

I would advocate the following policy for uploading scores to IMSLP:

1) PDF is required.
2) .mus, .sib, and MusicXML .xml / .mxl are welcome in addition. MusicXML is specifically encouraged.
3) Any other format supported by software that is available for downloading gratis and without registration in both source and object form, and that can be installed on Windows, Mac, and Linux OSs without downloading additional libraries, is acceptable. This would include, for example, mup (http://www.arkkra.com, my personal favorite). It would not include Lilypond, which requires downloading a large number of libraries, some of them in specific versions.
pml
Copyright Reviewer
Posts: 1219
Joined: Fri Mar 16, 2007 3:42 am
notabot: 42
notabot2: Human
Location: Melbourne, Australia
Contact:

Re: Request for Comments: Deprecation of MUS and SIB files

Post by pml »

Thanks for the info on that interesting discussion on MusicXML. However, I still can't see any need for anything other than PDFs, given that you can attach any other type of source file that you want to a PDF (I've just tested this myself using pdftk - see http://www.pdfhacks.com/pdftk/ ). There is no reason at all - beyond the incompetence of contributors - for anyone to need to upload a score in any other format than PDF.

Regards, Philip
--
PML (talk)
zap
Posts: 2
Joined: Tue Apr 06, 2010 8:58 am
notabot: 42
notabot2: Human

Re: Request for Comments: Deprecation of MUS and SIB files

Post by zap »

With the greatest respect to Philip, a respected and prolific contributor to both cpdl and impslp, the problem of simply appending to a pdf is that it's not searchable. And the whole point of the internet is that it's searchable, that we don't prescribe what any given user might want to do with the information.
So, to teach an arranging class for instance, or arrange whatever pieces for, say, wind quintet with that includes a keen saxophone student... I would like to be able to search for sibelius, finale, or xml scores (according to choice). Likewise with the blind Chinese chap, who would like to perform a self-evidently valuable service in providing braille notations for existing scores.
At the moment I have discovered no effective way to search for .sib files, and the word "deprecate", or indeed any insistence on pdf only will/does discourage people from bothering to upload original notation versions. That people shoudl be sitting at opposite ends of the globe re-inputting masterworks into notation programmes because there's no searchable central repository seems extrodinarily short-sighted...
Lyle Neff
active poster
Posts: 702
Joined: Wed Mar 14, 2007 3:21 pm
notabot: 42
notabot2: Human
Location: Delaware, USA
Contact:

Re: Request for Comments: Deprecation of MUS and SIB files

Post by Lyle Neff »

This may have been brought up before, but attachments to a PDF can be a problem if they are not what they are purported to be. The copyright reviewers would always have to have the latest version of Finale, Sibelius, etc., in order to have the capacity just to read attached files, to make sure they are what they are, and not some Trojan attempt to infringe copyright. (I'm not a copyright reviewer, but the latest version of Finale that I have is 2006, which means that I can't see .mus files created with later versions of Finale.)
"A libretto, a libretto, my kingdom for a libretto!" -- Cesar Cui (letter to Stasov, Feb. 20, 1877)
KGill
Copyright Reviewer
Posts: 1295
Joined: Thu Apr 09, 2009 10:16 pm
notabot: 42
notabot2: Human

Re: Request for Comments: Deprecation of MUS and SIB files

Post by KGill »

That's an excellent point. One of the reasons that by now only PDFs are allowed is that virtually every single person with an Internet connection can open them. Having a bunch of different formats would make the site a lot harder to maintain - even if PDFs were still required. Also, MUS, SIB, and ZIP files are insecure (hence the warning the site has whenever you access their file pages), while PDFs are not; yet another opening for someone to destabilize the site. Sure, the file would be deleted if it contained malicious information, but not before it worked its magic on a CR's machine. I'm with Feldmahler on this - limiting the site to PDFs is a lot simpler, and I will always support it.
What we could do is either encourage users to upload the source files for their typesets to other sites (and link to them from IMSLP), or even create a sister site just for typesets (Feldmahler has quite enough on his plate right now, so someone else would have to set it up. We maybe could also only allow MUS and SIB files and tell people to submit Lilypond files to Mutopia) - although that would also create a large new area for maintenance.
I have discovered no effective way to search for .sib files
Maybe this is partly because there are something like a dozen of those files on the entire site? :wink:
pml
Copyright Reviewer
Posts: 1219
Joined: Fri Mar 16, 2007 3:42 am
notabot: 42
notabot2: Human
Location: Melbourne, Australia
Contact:

Re: Request for Comments: Deprecation of MUS and SIB files

Post by pml »

I don't know that there's a good answer to KGill's comment on insecurities in any of the file types uploaded to IMSLP - usually in my CR duties I only investigate the PDF, and if there are attached files I don't usually go to the trouble of pulling them out and also examining those; if the files were separately linked from the Wiki rather than being PDF attachments, I would likely be similarly disinclined to examine them (i.e., I would probably not be bothered, provided there was an apparently usable PDF). It would be far from impossible for someone to concoct a malicious file and upload it to the site, but I doubt the exercise would be worth the effort given how many hits any individual item is likely to receive.

Whether files are searchable is highly dependent on the media type, but I concede a .sib or .mus file attached within a .pdf is inherently less obvious than a link to the original file.
--
PML (talk)
zap
Posts: 2
Joined: Tue Apr 06, 2010 8:58 am
notabot: 42
notabot2: Human

Re: Request for Comments: Deprecation of MUS and SIB files

Post by zap »

Maybe this is partly because there are something like a dozen of those files on the entire site? :wink:
...whereas on cpdl (ChoralWiki) there are hundreds, that i'm always transposing up or down a few keys or re-arranging according to the voices at hand. I work in a University, and just want our instrumental students to have a similar access to repertoire. At the moment it's easier to teach chamber music, style and intonation from cpdl madrigals and motets than by extracting/arranging from the genuine masterworks written for instrumentalists.

It's simply happens to be that there are hundreds more students learning the clarinet than play the oboe, for instance, ditto the violin/viola. Without some source files, nurturing a love of Chamber music or ensemble playing at an intermediate level continues to depend exclusively on the availability/standard of a few students studying less common instruments.

Maybe Philip could comment on whether cpdl's policies have caused undue admin hassle or violations? It would be interesting to have some download figures from a page like the Mozart Cminor mass page, to see how many people were interested in the .sib file compared to the pdf parts.
http://www2.cpdl.org/wiki/index.php/Gre ... _Mozart%29

...with continued thanks for his very substantial and worthwhile input to music performance...
Post Reply