Re: [Finale] editing chord symbols enharmonically
Chord Tool Menu - Simplify Spelling often takes care of most of this. Chuck On Nov 28, 2013, at 10:59 AM, John Witmer wit...@nctv.com wrote: Sorry if this message is a repeat; I got lost in the ether. In editing Christmas music for amateur singers (and pianists), I have to transpose many songs to fit the range of elder singers. In some keys this produces results such as double flats that are difficult for many amateurs to read. Even though the double flats are technically correct, is there some way to keep (or change) the chord symbols to their enharmonic equivalent? I use Finale '12. John Witmer Clemson Downs Retirement Center Clemson, SC John Witmer Clemson Downs Clemson, SC ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale Chuck Israels 8831 SE 12th Ave. Portland, OR 97202-7097 land line: (503) 954-2107 cell phone: (360) 201-3434 www.chuckisraelsjazz.com ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing a track
Thanks David. Looks easy enough to use and will probably do what I need it to do.. David McKay On 22 July 2010 08:22, David W. Fenton lists.fin...@dfenton.com wrote: On 22 Jul 2010 at 8:12, David McKay wrote: I'm wondering if someone can tell me where there is a simple cheap or free program which I can use to cut up a track into smaller bits. I used to do this with Nero, but no longer own it. I was disappointed with Nero crashing [crash and burn ...?] and don't own a copy any more. What I want to do is to cut up a recording of a Brahms piano quartet movement which students are studying for a theory exam, so that they can have different parts to recognise, such as an excerpt of the second subject, etc. Have you tried Audacity? -- David W. Fentonhttp://dfenton.com David Fenton Associates http://dfenton.com/DFA/ ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale -- www.gontroppo.blogspot.com ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing a track
On 22 Jul 2010 at 8:33, David McKay wrote: Looks easy enough to use and will probably do what I need it to do.. I've been using it for several years, and though it's not the greatest UI, it keeps getting more capable over the years. And you can't beat the price! -- David W. Fentonhttp://dfenton.com David Fenton Associates http://dfenton.com/DFA/ ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing a track
On 7/21/2010 6:12 PM, David McKay wrote: I'm wondering if someone can tell me where there is a simple cheap or free program which I can use to cut up a track into smaller bits. http://audacity.sourceforge.net Aaron. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
RE: [Finale] Editing 2009 files in 2010
I thought I'd update the list on my inability to open my 2009 documents in 2010. It is a known problem to MakeMusic that a 'handful' of people have encountered. The best information I've received is that it is a problem with templates. They've asked me how far back in versions was the original template made (not sure - maybe 2003, maybe 3.7) and if I had converted the template from old versions to new versions (yes, of course). The problem has been passed to the research people, then the quality assurance people, and now I'm told that it is back with research. They can't tell me at this point if a maintenance upgrade will have the problem fixed or not. In the meanwhile, I'm trying my hand with Sibelius 6 (after using Finale exclusively since version 3.7) and after only a few days with it, I'm not seeing any compelling reason not to stick with it, but it is early days. James Gilbert ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
RE: [Finale] Editing 2009 files in 2010
Thank you (and to others) that offered to send a test file. I've received the following from MakeMusic: Make music tech I looked over the file and it looks like it is damaged. To fix it, open the file and go to the File menu MusicXML Export. Next, close the original version of the file. Go back to the File menu MusicXML Import, select the recently exported file and click Open. This should solve the error you are receiving. Please feel free to respond to this case if you have any further questions about this issue. I did all of the above in 2010 and it does work. So, for the handful of new files I recently started in 2009, this solves that issue. I can update my templates the same way. In the past I've converted all my old files to the most current version to keep everything up to date. However, this time the task of exporting/importing/saving thousands of files may change my mind and maybe I'll just keep 2008, 2009 2010 all running on the same system. Hopefully that's not a problem. I'd like to know how so many files got damaged (at least 20 far that I've tried to open have given me problems). Thanks again, James Gilbert www.jamesgilbertmusic.com -Original Message- From: finale-boun...@shsu.edu [mailto:finale-boun...@shsu.edu] On Behalf Of Noel Stoutenburg Sent: Thursday, June 11, 2009 10:42 PM To: finale@shsu.edu Subject: Re: [Finale] Editing 2009 files in 2010 James: One thing that you might want to try, is to forward one of the offending files to someone else, and see if they have problems opening it in 2k10. I have a 2k9 test file that I created, that I'd be willing to send you, too, if you want to see if you have the problem with a file created by someone else. ns ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
RE: [Finale] Editing 2009 files in 2010
On 12 Jun 2009 at 13:48, James Gilbert wrote: Make music tech I looked over the file and it looks like it is damaged. To fix it, open the file and go to the File menu MusicXML Export. Next, close the original version of the file. Go back to the File menu MusicXML Import, select the recently exported file and click Open. This should solve the error you are receiving. Please feel free to respond to this case if you have any further questions about this issue. Have you run the repair tools in your earlier version of Finale? Specifically, on the OPTIONS | DATA CHECK menu, run TEST FILE INTEGRITY and REMOVE DELETED ITEMS. Then try importing. I would not want to use the MusicXML intermediary since it could lose things that are important to the layout. I don't know for certain that it would, but the fact of it being an intermediary format gives me pause. If you can repair the original file, that seems to me to be a better solution. But, of course, it may not work. -- David W. Fentonhttp://dfenton.com David Fenton Associates http://dfenton.com/DFA/ ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
RE: [Finale] Editing 2009 files in 2010
Nice idea, but I had already tried the data check and file integrity on the files in both 2009 and 2010. Still have problems. For my immediate needs, converting to XML and back will work. For some stuff I'm arranging, I like to start from an existing piece and edit it to make a new arrangement. Using XML will be fine. I am leery of converting what you might call 'finished' pieces from older versions via XML. James Gilbert -Original Message- From: finale-boun...@shsu.edu [mailto:finale-boun...@shsu.edu] On Behalf Of David W. Fenton Sent: Friday, June 12, 2009 1:55 PM To: finale@shsu.edu Subject: RE: [Finale] Editing 2009 files in 2010 Have you run the repair tools in your earlier version of Finale? Specifically, on the OPTIONS | DATA CHECK menu, run TEST FILE INTEGRITY and REMOVE DELETED ITEMS. Then try importing. I would not want to use the MusicXML intermediary since it could lose things that are important to the layout. I don't know for certain that it would, but the fact of it being an intermediary format gives me pause. If you can repair the original file, that seems to me to be a better solution. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing 2009 files in 2010
James Gilbert wrote: maybe I'll just keep 2008, 2009 2010 all running on the same system. Hopefully that's not a problem. I can't comment on the specific combination of 2008, 2009, and 2010, but I have run several versions in parallel for years, and at present have 2000, 2003, 2006, and 2009 installed, and 2010 will be a fifth version installed. The only problems I recall with doing this seem to be related to either the MIDI or sound card interface subsystems. If I'm using one version, and open a second, MIDI or the sound system still work in one, but not on the second. It hasn't proved a significant enough problem that I've bothered to spend much time debugging the issues. ns ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing 2009 files in 2010
Oooh ... that's a little scary. However, I would be editing from Mac07, if that makes any difference ... I wonder. Please inform if it continues. I've been putting off some projects, so that I could start them in 2010 ... looks as if I may be happy that I did. Expecting it any day ... Dean On Jun 11, 2009, at 8:38 AM, James Gilbert wrote: I seem to be running into major problems editing FinWin 2009 files in 2010. The files open correctly in 2010 and everything is where it should be. When I then start to edit the file using speedy entry, things go a little haywire after exiting speedy entry. First I get an error saying the program cannot initialize the printer. Then, the display colors turn off putting everything into black white. If I use CTRL-4 (respacing) I get the same error multiple times. Then I can no longer move the page around via dragging or the navigation bars. I haven't tried to figure out any work arounds. If I find one, I'll post it. The bug has been reported to MakeMusic. Good news is that a document started in 2010 seems to work just fine. James Gilbert ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale Canto ergo sum And, I'd rather be composing than decomposing Dean M. Estabrook http://deanestabrook.googlepages.com/home ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing 2009 files in 2010
I have been using 2010 for a couple of weeks now on a Vista 32bit machine and have not experienced any of this with any of the files I have edited from 2009. I just tried the same things with some 2003, 2004 and 2007 files and still no problems. I'm sure you have already tried rebooting your computer. Have you tried re-installing 2010? Rick Neal James Gilbert wrote: I seem to be running into major problems editing FinWin 2009 files in 2010. The files open correctly in 2010 and everything is where it should be. When I then start to edit the file using speedy entry, things go a little haywire after exiting speedy entry. First I get an error saying the program cannot initialize the printer. Then, the display colors turn off putting everything into black white. If I use CTRL-4 (respacing) I get the same error multiple times. Then I can no longer move the page around via dragging or the navigation bars. I haven't tried to figure out any work arounds. If I find one, I'll post it. The bug has been reported to MakeMusic. Good news is that a document started in 2010 seems to work just fine. James Gilbert ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale -- Rick Neal Teacher, Composer, Arranger, Bassist, Guitarist rickm...@earthlink.net rickm...@gmail.com ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
RE: [Finale] Editing 2009 files in 2010
I'm using Windows Vista home premium with service pack 1 installed. Intel core duo cpu, 2gb ram, Radeon X1300/X1500 video card. I'm not having trouble with any other programs and the system isn't sluggish or otherwise different than normal. I have rebooted a few times, re-installed at least once, maybe twice, I forget. Nothing changes, Finale is unusable for me with files created in previous versions (at least 2009, 2008 2007). The only anomaly I've had was in the reinstall program, the computer initially had trouble reading the DVD and I had to eject and reinsert the disc to get vista to recognize it. Considering Finale and the Garritan sounds are all working fine for new files, I don't consider that to be a problem. I'll mention again, for new files, new projects, I can find no problems. The percussion changes are nice and the VST instrument setup is a little easier to work with. Not only do I have the troubles I've described previously opening older files, I've replicated the problem when importing XML versions of the same files. I've tried other things to track down the problem with no luck. I'll keep playing with it to see if any older files I have will work. James Gilbert -Original Message- From: finale-boun...@shsu.edu [mailto:finale-boun...@shsu.edu] On Behalf Of Rick Neal Sent: Thursday, June 11, 2009 1:45 PM I have been using 2010 for a couple of weeks now on a Vista 32bit machine and have not experienced any of this with any of the files I have edited from 2009. I just tried the same things with some 2003, 2004 and 2007 files and still no problems. I'm sure you have already tried rebooting your computer. Have you tried re-installing 2010? Rick Neal ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
RE: [Finale] Editing 2009 files in 2010
On 11 Jun 2009 at 18:32, James Gilbert wrote: Not only do I have the troubles I've described previously opening older files, I've replicated the problem when importing XML versions of the same files. I've tried other things to track down the problem with no luck. I'll keep playing with it to see if any older files I have will work. Do you have more than one printer installed? Even if it's just a PDF printer, try opening the old file in the old version, change the printer and print 1 page and save the file. Then try converting it to 2009. Printer data is stored in the file and is going to interact with the video card, and maybe the printer data structures are mucking things up. How it mucks up the XML export I can't say, but maybe whatever printer data/settings are causing the problems are captured in the XML export as well. -- David W. Fentonhttp://dfenton.com David Fenton Associates http://dfenton.com/DFA/ ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
RE: [Finale] Editing 2009 files in 2010
I have two physical printers installed (one of which has 3 separate incarnations in the control panel printer settings - each with a different type of driver), plus I have a handful of virtual printers (eg. adobe pdf, xps document printer, etc). I tried your suggestion below as well as changing the default printer. I've also made sure my system is up to date with the latest Microsoft updates and also made sure my video card driver was up to date. Even with all that - and having to reboot more times than I care to in a day - the same problem: open a 2007, 2008 or 2009 file in 2010, try to edit in speedy entry and upon exiting speedy entry, problems as previously described happen and I can't use the program. In addition to XML files saved in 2009 also giving me the same errors, templates (as one might expect) created in 2009 also give me the same problems. I've also discovered that doing any note entry via simple entry in such files gives me the same problems. Oh well. On the one hand I hope I'm not the only one with this problem as that means it is so obscure a problem I may never see a fix but on the other hand I don't want others to have to go through what I'm going through. At least I can start from scratch without a problem. James Gilbert www.jamesgilbertmusic.com -Original Message- From: finale-boun...@shsu.edu [mailto:finale-boun...@shsu.edu] On Behalf Of David W. Fenton Sent: Thursday, June 11, 2009 7:39 PM To: finale@shsu.edu Subject: RE: [Finale] Editing 2009 files in 2010 Do you have more than one printer installed? Even if it's just a PDF printer, try opening the old file in the old version, change the printer and print 1 page and save the file. Then try converting it to 2009. Printer data is stored in the file and is going to interact with the video card, and maybe the printer data structures are mucking things up. How it mucks up the XML export I can't say, but maybe whatever printer data/settings are causing the problems are captured in the XML export as well. -- David W. Fentonhttp://dfenton.com David Fenton Associates http://dfenton.com/DFA/ ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing 2009 files in 2010
James: One thing that you might want to try, is to forward one of the offending files to someone else, and see if they have problems opening it in 2k10. I have a 2k9 test file that I created, that I'd be willing to send you, too, if you want to see if you have the problem with a file created by someone else. ns ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing 2009 files in 2010
James, I would be willing to try one of the offending files since I am unable to duplicate the problems you are having with any of my earlier files. Just send it on if you would like for me to try it. Rick Noel Stoutenburg wrote: James: One thing that you might want to try, is to forward one of the offending files to someone else, and see if they have problems opening it in 2k10. I have a 2k9 test file that I created, that I'd be willing to send you, too, if you want to see if you have the problem with a file created by someone else. ns ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale -- Rick Neal Teacher, Composer, Arranger, Bassist, Guitarist rickm...@earthlink.net rickm...@gmail.com ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing 2009 files in 2010
I just installed 2010 (Windows). Imported a 2009 file, imported a graphic (MUCH easier - jpg, gif or tif, no complaining about compression after editing a tif in MSPaint) and saved it, printed it, called it up again, no problems. I also have two actual printers and some virtual printers. Raymond Horton Rick Neal wrote: James, I would be willing to try one of the offending files since I am unable to duplicate the problems you are having with any of my earlier files. Just send it on if you would like for me to try it. Rick Noel Stoutenburg wrote: James: One thing that you might want to try, is to forward one of the offending files to someone else, and see if they have problems opening it in 2k10. I have a 2k9 test file that I created, that I'd be willing to send you, too, if you want to see if you have the problem with a file created by someone else. ns ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing
Hello all. I just passed an exam in image and video techniques, and I can confirm that this is indeed feasible ;) The 13/2/09 23:22, Aaron Sherber escribió/wrote: (It makes a certain amount of sense. For example, with the right software you can rotate a JPG 90 deg. and save losslessly.) Aaron. And Mr. Fenton is right about what he said about not seeing further degradation after several saves. That coincides with the way JPEG Baseline compression works. [It makes blocks of 8 x 8 pixels values, performs a Discrete Cosine Transform -passing to the frequency domain-, quantize the matrix of coefficients (this is were the quality percentage is applied), and compress the new values (most of them are zeroes now) forming a bit stream that is sent to the file.] (Incidentally, as an assignment l had to program a plug-in in C for the GIMP program, in order to compare the different qualities achieved with the JPEG compression. Fun stuff...) All the best, Javier Ruiz ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing
On Feb 19, 2009, at 4:56 PM, Javier Ruiz wrote: Javier wrote: (snip) [It makes blocks of 8 x 8 pixels values, performs a Discrete Cosine Transform -passing to the frequency domain-, quantize the matrix of coefficients (this is were the quality percentage is applied), and compress the new values (most of them are zeroes now) forming a bit stream that is sent to the file.] I am in awe of such technical expertise and fluency of patois. I must admit, I understand absolutely nothing (except individual words, for the most part) of the above paragraph. It reminds me of one of my favorite Charlie Brown cartoons, in which Charlie, Lucy and the piano player (Can't remember his name at the moment) are lying on their backs staring at clouds passing overhead. Lucy says something like, Ah yes, I see the Reformation struggle of Christianity, the next one observes, For me, the shapes represent a typical Rorschach test, and Charlie thinks (in the bubble), I was going to say I thought I saw a lamb and a doggie, but I'm going to keep it to myself. Count me in on the Charlie side. Cheers, Dean ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale Canto ergo sum Dean M. Estabrook http://deanestabrook.googlepages.com/home ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing
David W. Fenton wrote: On 13 Feb 2009 at 16:07, dhbailey wrote: Of course the player you saw may have been playing a pocket trumpet which is simply a regular Bb trumpet, predominently cylindrical bore and all, full length but just wrapped around more so it's short enough to fit into a pocket. Not that people wear coats with pockets that large any more. That would make no sense, given that he had a normal Bb trumpet that he also played by itself. He also played the strange trumpet by itself, and it seemed to have a mellower sound than the Bb, which would suggest that it might very well have been a cornet. The combo as a whole was really quite good -- all the players were excellent (but especially the guitarist). I felt fortunate to have had my train delayed so that I got the opportunity to hear them play 3 different pieces. I certainly can't argue with you, since you were there and I wasn't, but pocket trumpets do have a more mellow tone than a normally shaped trumpet because of the extra wraps in the tubing. And I can understand his desire to use a cornet or a pocket trumpet when playing with the two instruments in order to make holding them up more comfortable, since the arm holding the cornet/trumpet wouldn't be as much extended in front as with a traditionally shaped trumpet. In any event, that sort of incident you describe, a moment of musical wonder and beauty in the midst of the hustle and bustle of a big city is one of the very few reasons that I wish I lived in a city. That opportunity to see how vast is the creativity of people is something special! I hope you get to see them again! -- David H. Bailey dhbai...@davidbaileymusicstudio.com ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing
Richard Yates wrote: (It's the same with images. If someone sends you a JPG that you plan to edit repeatedly, you should first open it and save it as a TIF, and then make all your edits to the TIF. When you're done editing, you can export the TIF as a JPG for portability, keeping your source TIF for any further changes. If you edit and save as JPG, you incur loss and introduce artifacts each time.) As I said in another post, I think this is incorrect, also. David Fenton I have heard the first theory and decided to test it. I opened a high resolution photo in Photoshop and saved it with the maximum compression as a jpg. Then reopened it and saved again with maximum compression. After repeating this seven times I can see no further degradation after the first compression. The file size remains exactly the same also. David Fenton appears to be right. (I have no idea if this applies to mp3s, though.) I wonder if this is because there has been standardization of the data that is tossed in the compression, so that if that specific data isn't in the picture anymore because it had been tossed in a previous compression, it isn't there to toss again, and the compression routine won't randomly toss other data just to satisfy the object of compression. Richard, with all those subsequent compression-saves, did the size of the file actually get smaller, or did it remain the same despite additionial compression? -- David H. Bailey dhbai...@davidbaileymusicstudio.com ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing
Aaron Sherber wrote: [snip] Also -- and I admit this isn't particularly relevant here -- comparing file sizes isn't really an adequate way of comparing the files. You're saying that because one file is only a few bytes bigger or smaller, there can't be much difference between the two. But of course, even if the two JPGs were exactly the same size, the actual data could be wildly different. [snip] While I agree that the actual data within the file could be wildly different between two differently saved files, I would think that opening a file which was originally 100% (zero compression) and then compressing that 50% and saving the file, shouldn't the resulting file be significantly smaller than the original? And then if you open that 50% compressed file and then do a new save at 50% compression, shouldn't this 3rd file be significantly smaller than the 2nd file? But in reality is there a significant difference in additional saves at 50% compression? If there is, then there should be a visible degradation, even if it's only viewable at a percentage such as 200% or more when viewing the newly compressed file. -- David H. Bailey dhbai...@davidbaileymusicstudio.com ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing
On 14.02.2009 dhbailey wrote: While I agree that the actual data within the file could be wildly different between two differently saved files, I would think that opening a file which was originally 100% (zero compression) and then compressing that 50% and saving the file, shouldn't the resulting file be significantly smaller than the original? And then if you open that 50% compressed file and then do a new save at 50% compression, shouldn't this 3rd file be significantly smaller than the 2nd file? But in reality is there a significant difference in additional saves at 50% compression? If there is, then there should be a visible degradation, even if it's only viewable at a percentage such as 200% or more when viewing the newly compressed file. No, this kind of compression always works from the raw data, ie the individual pixels or samples, depending on the media. So recompressing a jpg with the same compression ratio, while making it lower quality, will not make it smaller. Johannes ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing
On 14 Feb 2009 at 7:26, dhbailey wrote: In any event, that sort of incident you describe, a moment of musical wonder and beauty in the midst of the hustle and bustle of a big city is one of the very few reasons that I wish I lived in a city. That opportunity to see how vast is the creativity of people is something special! I hope you get to see them again! I asked my roommate about playing two instruments at once (he's a former low brass player), and he said he'd seen it. As I gave him more details about the group, he realized he'd seen the same group in Central Park a few months ago. So, they apparently get around. -- David W. Fentonhttp://dfenton.com David Fenton Associates http://dfenton.com/DFA/ ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing
On 2/13/2009 11:57 AM, Dean M. Estabrook wrote: I just made a recording of a choir rehearsal last night with my H2 digital. I recorded in the MP3 mode. It is possible to edit said files (other than just splitting a file on the H2) once they are uploaded to my Mac? I believe that most audio editing programs are able to open MP3s. Take a look, for example, at the open source Audacity: http://audacity.sourceforge.net However, keep in mind that MP3s are like JPG images -- they use lossy compression, meaning every time you edit and save, you introduce some artifacts (which may or may not be audible/visible). This is why it's always better to record and edit in a non-lossy format like WAV or AIFF, and then convert to MP3 if needed when you're sending the finished product to someone else. What you might want to do is open this MP3 in Audacity and save it as a WAV. Then you can edit, save, edit, save, etc. as much as you like with the WAV without further degradation of the original MP3. And then again, only convert your finished WAV to MP3 when you're done, if needed. Aaron. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing
Good info ... thanks. Dean On Feb 13, 2009, at 9:15 AM, Aaron Sherber wrote: On 2/13/2009 11:57 AM, Dean M. Estabrook wrote: I just made a recording of a choir rehearsal last night with my H2 digital. I recorded in the MP3 mode. It is possible to edit said files (other than just splitting a file on the H2) once they are uploaded to my Mac? I believe that most audio editing programs are able to open MP3s. Take a look, for example, at the open source Audacity: http:// audacity.sourceforge.net However, keep in mind that MP3s are like JPG images -- they use lossy compression, meaning every time you edit and save, you introduce some artifacts (which may or may not be audible/visible). This is why it's always better to record and edit in a non-lossy format like WAV or AIFF, and then convert to MP3 if needed when you're sending the finished product to someone else. What you might want to do is open this MP3 in Audacity and save it as a WAV. Then you can edit, save, edit, save, etc. as much as you like with the WAV without further degradation of the original MP3. And then again, only convert your finished WAV to MP3 when you're done, if needed. Aaron. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale Canto ergo sum Dean M. Estabrook http://deanestabrook.googlepages.com/home ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing
On 13 Feb 2009, at 12:15 PM, Aaron Sherber wrote: What you might want to do is open this MP3 in Audacity and save it as a WAV. Then you can edit, save, edit, save, etc. as much as you like with the WAV without further degradation of the original MP3. And then again, only convert your finished WAV to MP3 when you're done, if needed. With respect, Aaron, this won't help. Converting the MP3 to WAV and back again will introduce far more artifacts than any edits you might make in Audacity, and won't actually result in any benefit. Once a file is in a lossy format (like MP3), up-converting it to a non-lossy format won't restore any missing audio data and will actually result in a file that sounds *worse* than the original MP3. Once you are in MP3 format, that sonic detail you'd have in a lossless format like WAV is gone -- or, if the file was recorded as an MP3, was never there in the first place -- and is impossible to recover. Best to make edits in the original MP3 format to avoid the further sonic degradation of up- sampling and then down-sampling again. Cheers, - Darcy - djar...@mac.com Brooklyn, NY ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing
On 13 Feb 2009 at 12:15, Aaron Sherber wrote: However, keep in mind that MP3s are like JPG images -- they use lossy compression, meaning every time you edit and save, you introduce some artifacts (which may or may not be audible/visible). This is why it's always better to record and edit in a non-lossy format like WAV or AIFF, and then convert to MP3 if needed when you're sending the finished product to someone else. Audacity does not edit in the original format -- it imports *all* formats into its own format and you edit in that. Thus, you never lose anything beyond the quality already lost by creation of the MP3 itself. That is, the sound quality won't be worsened by editing in Audacity. -- David W. Fentonhttp://dfenton.com David Fenton Associates http://dfenton.com/DFA/ ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing
On 13 Feb 2009 at 13:19, Darcy James Argue wrote: With respect, Aaron, this won't help. Converting the MP3 to WAV and back again will introduce far more artifacts than any edits you might make in Audacity, and won't actually result in any benefit. Once a file is in a lossy format (like MP3), up-converting it to a non-lossy format won't restore any missing audio data and will actually result in a file that sounds *worse* than the original MP3. Once you are in MP3 format, that sonic detail you'd have in a lossless format like WAV is gone -- or, if the file was recorded as an MP3, was never there in the first place -- and is impossible to recover. Best to make edits in the original MP3 format to avoid the further sonic degradation of up- sampling and then down-sampling again. I'm surprised at this assertion, Darcy. When you convert an MP3 to WAV, you're taking the wave form that you get when you expand it from the MP3 and fixing it in a final wave form. There should be absolutely no artifacts from converting form MP3 to WAV. Indeed, the waveform of the WAV file should be exactly what you get from playback of the MP3. Secondly, Audacity never edits the MP3 or WAV directly. Instead, you import the source MP3 or WAV into Audacity's own format (which uses a lot of tiny little files, and stores edits as additional files that record the delta from the original source). To then save an MP3 or WAV file from the Audacity editing session, you have to export it to the external format. Audacity introduces no conversion artifacts during this process. And it shouldn't, because the wave form that is output from an MP3 file is not variable -- it's a fixed wave form that can be described without any loss of information by any lossless audio format. On another note, I saw something that seemed pretty incredible to me today. On the subway platform at Columbus Circle, there was a really fine jazz quartet (bass, drums, guitar, trumpet) performing. All the players were really excellent and I was lucky that the trains were delayed and got a chance to listen to them at length (I contributed a $5 bill, since I felt $1 was too little for a 4-piece group). Anway, the incredible part (to me) was that the trumpet player would simultaneously play both trumpet and flugel horn, the trumpet on the left side of his mouth, the flugel on the right. He'd mostly play unisons, but occasionally he'd play in octaves and in harmony with himself. It was awesome. He actually had another trumpet, and the trumpet he played with the flugel horn did not look like a normal Bb trumpet (while the other one did) -- it looked like it had shorter tubing (the tubing was bent more like a cornet, thought it was clearly not a cornet at all -- the mouthpiece and bore were clearly a trumpet). But it did seem to me that when he was playing in unison that he was using the same fingering for both, so it surely wasn't in a different key. Anyway, I was blown away by the fact that someone could pull of this stunt, but he didn't just managing it, like the dog walking on its hind legs -- he was actually quite good and played in tune with himself. There was even flutter tonguing! Is this something that trumpet players do a lot as a virtuosic stunt? Or was this really unusual? I love New York. -- David W. Fentonhttp://dfenton.com David Fenton Associates http://dfenton.com/DFA/ ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing
On 13 Feb 2009, at 4:02 PM, Aaron Sherber wrote: Hmm. I was unaware that there were mainstream apps that could edit MP3s natively. There certainly are. You can open an MP3 in QuickTime Player and edit it directly there without converting to some other format. And Fission (the app I use to split long single audio files recorded at my gigs into individual tracks and normalize them) also works on whatever audio format you begin with, without converting anything. I assumed that the process was like working with JPGs -- if you have a JPG as a source, you open it and save it as a TIF or something else non-lossy so it won't get any worse while you work on it. If you edit the JPG and save back as a JPG, it gets worse each time, because you're re-applying the lossy compression to something that was lossy to begin with. Am I incorrect? You are right that that up-sampling *shouldn't* introduce any new artifacts. But if you take an MP3, up-sample it and save as WAV, and then (without editing anything) down-sample it and save it as an MP3, the resultant MP3 will sound worse than the original MP3. I don't use Audacity so I'm not familiar with what goes on under the hood. But if Audacity works in its own native format, that strikes me as even more of a reason not to save the file out as a WAV file before editing, since (if I understand the situation correctly) any work you do in Audacity will always be done in its own native format. Cheers, - Darcy - djar...@earthlink.net Brooklyn, NY ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing
As I recall, even iTunes, for either platform, will permit editing and it's free noel jones ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing
On 2/13/2009 4:19 PM, Darcy James Argue wrote: On 13 Feb 2009, at 4:02 PM, Aaron Sherber wrote: Hmm. I was unaware that there were mainstream apps that could edit MP3s natively. There certainly are. You can open an MP3 in QuickTime Player and edit it directly there without converting to some other format. And Fission (the app I use to split long single audio files recorded at my gigs into individual tracks and normalize them) also works on whatever audio format you begin with, without converting anything. That goes against my understanding; I'll have to look into it some more. You are right that that up-sampling *shouldn't* introduce any new artifacts. But if you take an MP3, up-sample it and save as WAV, and then (without editing anything) down-sample it and save it as an MP3, the resultant MP3 will sound worse than the original MP3. Yes, but that's not because of the *upsampling* -- it's because of the subsequent re-downsampling. as even more of a reason not to save the file out as a WAV file before editing, since (if I understand the situation correctly) any work you do in Audacity will always be done in its own native format. Yes, but Audacity's native format is still lossless, like WAV, so there's no penalty there. Aaron. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
RE: [Finale] Editing
Darcy, you are mistaken. You cannot edit an mp3 in native mode as it is an encoded format. It may look to you as if you are directly editing the mp3 when you open it, but any audio editor must of course convert the file to an audio waveform before it can be edited (whether WAV, AIFF, or a native internal format). I suppose you could edit the raw mp3 data, but that would be quite useless -- it's just bits and bytes, not audio. You are correct that every stage of conversion to and from mp3 (or any lossy format) can potentially degrade quality compared to the original; the degree of degradation will depend on the amount of compression. This will be equally true in QuickTime Player as any other editor. Lee Actor (former digital signal processing expert in another life) Composer-in-Residence and Assistant Conductor, Palo Alto Philharmonic Assistant Conductor, Nova Vista Symphony http://www.leeactor.com On 13 Feb 2009, at 4:02 PM, Aaron Sherber wrote: Hmm. I was unaware that there were mainstream apps that could edit MP3s natively. There certainly are. You can open an MP3 in QuickTime Player and edit it directly there without converting to some other format. And Fission (the app I use to split long single audio files recorded at my gigs into individual tracks and normalize them) also works on whatever audio format you begin with, without converting anything. I assumed that the process was like working with JPGs -- if you have a JPG as a source, you open it and save it as a TIF or something else non-lossy so it won't get any worse while you work on it. If you edit the JPG and save back as a JPG, it gets worse each time, because you're re-applying the lossy compression to something that was lossy to begin with. Am I incorrect? You are right that that up-sampling *shouldn't* introduce any new artifacts. But if you take an MP3, up-sample it and save as WAV, and then (without editing anything) down-sample it and save it as an MP3, the resultant MP3 will sound worse than the original MP3. I don't use Audacity so I'm not familiar with what goes on under the hood. But if Audacity works in its own native format, that strikes me as even more of a reason not to save the file out as a WAV file before editing, since (if I understand the situation correctly) any work you do in Audacity will always be done in its own native format. Cheers, - Darcy - djar...@earthlink.net Brooklyn, NY ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing
Hi Lee, Okay, that makes sense. Thanks for setting me straight. Cheers, - Darcy - djar...@earthlink.net Brooklyn, NY On 13 Feb 2009, at 4:55 PM, Lee Actor wrote: Darcy, you are mistaken. You cannot edit an mp3 in native mode as it is an encoded format. It may look to you as if you are directly editing the mp3 when you open it, but any audio editor must of course convert the file to an audio waveform before it can be edited (whether WAV, AIFF, or a native internal format). I suppose you could edit the raw mp3 data, but that would be quite useless -- it's just bits and bytes, not audio. You are correct that every stage of conversion to and from mp3 (or any lossy format) can potentially degrade quality compared to the original; the degree of degradation will depend on the amount of compression. This will be equally true in QuickTime Player as any other editor. Lee Actor (former digital signal processing expert in another life) Composer-in-Residence and Assistant Conductor, Palo Alto Philharmonic Assistant Conductor, Nova Vista Symphony http://www.leeactor.com On 13 Feb 2009, at 4:02 PM, Aaron Sherber wrote: Hmm. I was unaware that there were mainstream apps that could edit MP3s natively. There certainly are. You can open an MP3 in QuickTime Player and edit it directly there without converting to some other format. And Fission (the app I use to split long single audio files recorded at my gigs into individual tracks and normalize them) also works on whatever audio format you begin with, without converting anything. I assumed that the process was like working with JPGs -- if you have a JPG as a source, you open it and save it as a TIF or something else non-lossy so it won't get any worse while you work on it. If you edit the JPG and save back as a JPG, it gets worse each time, because you're re-applying the lossy compression to something that was lossy to begin with. Am I incorrect? You are right that that up-sampling *shouldn't* introduce any new artifacts. But if you take an MP3, up-sample it and save as WAV, and then (without editing anything) down-sample it and save it as an MP3, the resultant MP3 will sound worse than the original MP3. I don't use Audacity so I'm not familiar with what goes on under the hood. But if Audacity works in its own native format, that strikes me as even more of a reason not to save the file out as a WAV file before editing, since (if I understand the situation correctly) any work you do in Audacity will always be done in its own native format. Cheers, - Darcy - djar...@earthlink.net Brooklyn, NY ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing
On 2/13/2009 5:25 PM, Darcy James Argue wrote: Instead, my first suggestion would be to use an editing application that operates on the original MP3 file and does not require you to re- encode -- which, as far as I know, is what is happening with the app I use (Fission). I don't believe that is true, although I don't have direct experience with Fission. But David's and Lee's comments seem to back me up. Looking around a bit more on the web, I do think we need to distinguish different kinds of editing. It appears that certain kinds of edits can be made to MP3s without needing to recode, namely splitting up an MP3 into pieces and applying gain. (See http://sherber.com/url/3c , for example.) Other kinds of edits I think require re-encoding. Failing that: assuming David is correct that Audacity has its own native format, then Step 1 above seems unnecessary. Just open the MP3 in Audacity, make the edit, then save back to MP3. Yes -- unless you plan to do more editing. Keeping in mind that every save to MP3 format degrades quality, what you want to avoid is open the MP3, make an edit, save back to MP3. Open the new MP3 a week later, make some more edits, save back to MP3. Repeat again the next day. You've now re-saved as MP3 3 times, introducing more artifacts along the way. If you open the MP3 and save your intermediate work each time as a WAV, you incur no further loss penalty until you're done and you convert your WAV to MP3 to share with others. (It's the same with images. If someone sends you a JPG that you plan to edit repeatedly, you should first open it and save it as a TIF, and then make all your edits to the TIF. When you're done editing, you can export the TIF as a JPG for portability, keeping your source TIF for any further changes. If you edit and save as JPG, you incur loss and introduce artifacts each time.) Aaron. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing
On 13 Feb 2009, at 6:05 PM, Aaron Sherber wrote: Yes -- unless you plan to do more editing. Keeping in mind that every save to MP3 format degrades quality, what you want to avoid is open the MP3, make an edit, save back to MP3. Open the new MP3 a week later, make some more edits, save back to MP3. Repeat again the next day. You've now re-saved as MP3 3 times, introducing more artifacts along the way. If you open the MP3 and save your intermediate work each time as a WAV, you incur no further loss penalty until you're done and you convert your WAV to MP3 to share with others. Good point. I hadn't considered that factor. Cheers, - Darcy - djar...@earthlink.net Brooklyn, NY ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing
Hi Aaron, Looking around a bit more on the web, I do think we need to distinguish different kinds of editing. It appears that certain kinds of edits can be made to MP3s without needing to recode, namely splitting up an MP3 into pieces and applying gain. (See http://sherber.com/url/3c , for example.) Other kinds of edits I think require re-encoding. These are, in fact, the only kinds of edits Fission allows (cut paste, normalization and fades), which is, I suppose, why they are able to make the following claim (and why I thought they were editing the MP3 files directly): Fission also works with compressed MP3 and AAC formats to edit without the quality loss caused by other editors http://www.rogueamoeba.com/fission/ Cheers, - Darcy - djar...@earthlink.net Brooklyn, NY ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing
On 2/13/2009 6:15 PM, Darcy James Argue wrote: These are, in fact, the only kinds of edits Fission allows (cut paste, normalization and fades), Ah, interesting. Lee, can you comment on this? Is it true that these kinds of edits can be made to an MP3 without needing to recode afterwards? (It makes a certain amount of sense. For example, with the right software you can rotate a JPG 90 deg. and save losslessly.) Aaron. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing
iTunes lets you make volume adjustments and change the start and stop time. File - Info - Options. But these don't get written into the file itself, I don't think. - Darcy - djar...@earthlink.net Brooklyn, NY On 13 Feb 2009, at 6:19 PM, Dean M. Estabrook wrote: I haven't seen any capabilities in iTunes for editing. Perhaps I just don't know where to find them. Dean On Feb 13, 2009, at 1:48 PM, noel jones wrote: As I recall, even iTunes, for either platform, will permit editing and it's free noel jones ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale Canto ergo sum Dean M. Estabrook http://deanestabrook.googlepages.com/home ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
RE: [Finale] Editing
I'm not familiar with the internals of the mp3 format, so I can't say for sure. But considering that none of the edits mentioned operate in the frequency domain (such as filters and most other types of audio processing), I can see how it might be possible without conversion/reconversion. But don't quote me on that. -Lee On 2/13/2009 6:15 PM, Darcy James Argue wrote: These are, in fact, the only kinds of edits Fission allows (cut paste, normalization and fades), Ah, interesting. Lee, can you comment on this? Is it true that these kinds of edits can be made to an MP3 without needing to recode afterwards? (It makes a certain amount of sense. For example, with the right software you can rotate a JPG 90 deg. and save losslessly.) Aaron. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing
iTunes allows you to convert among a few formats, but that's it AFAIK. --AF On Feb 13, 2009, at 5:19 PM, Dean M. Estabrook d.e...@comcast.net wrote: I haven't seen any capabilities in iTunes for editing. Perhaps I just don't know where to find them. Dean On Feb 13, 2009, at 1:48 PM, noel jones wrote: As I recall, even iTunes, for either platform, will permit editing and it's free noel jones ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale Canto ergo sum Dean M. Estabrook http://deanestabrook.googlepages.com/home ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing
On 13 Feb 2009 at 16:02, Aaron Sherber wrote: if you have a JPG as a source, you open it and save it as a TIF or something else non-lossy so it won't get any worse while you work on it. If you edit the JPG and save back as a JPG, it gets worse each time, because you're re-applying the lossy compression to something that was lossy to begin with. Am I incorrect? I'm not sure what you're using for graphics editing, but if it applies the chosen compression ration with each save, it's very badly designed. The usual method is to have, say, a 15% compression ratio. When you open a file, your graphics editing progam knows what the compression ratio that it was saved at is, and if it was saved at 10%, it will compress to 15%. But if it's already 15%, it won't compress it any more than it already was. I do lots of graphics editing and while I keep TIFs as my source files, I do lots of editing in JPGs once the graphic has reaced a certain point in the editing process. And that includes multiple edits and multiple saves, and the quality does not decrease with each save. As you suggest, MP3s are not directly editable by any application I know of -- instead, you edit a copy of the waveform described in the MP3 file. Thus, there's no loss of quality. -- David W. Fentonhttp://dfenton.com David Fenton Associates http://dfenton.com/DFA/ ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing
Dean, my 2c, esp. since you are on Mac: Amadeus Pro is excellent. It costs some money, but unlike Audacity (in my experience) it's extremely stable and does a great job. I recommend it. Matthew 2009/2/14 David W. Fenton lists.fin...@dfenton.com On 13 Feb 2009 at 16:02, Aaron Sherber wrote: if you have a JPG as a source, you open it and save it as a TIF or something else non-lossy so it won't get any worse while you work on it. If you edit the JPG and save back as a JPG, it gets worse each time, because you're re-applying the lossy compression to something that was lossy to begin with. Am I incorrect? I'm not sure what you're using for graphics editing, but if it applies the chosen compression ration with each save, it's very badly designed. The usual method is to have, say, a 15% compression ratio. When you open a file, your graphics editing progam knows what the compression ratio that it was saved at is, and if it was saved at 10%, it will compress to 15%. But if it's already 15%, it won't compress it any more than it already was. I do lots of graphics editing and while I keep TIFs as my source files, I do lots of editing in JPGs once the graphic has reaced a certain point in the editing process. And that includes multiple edits and multiple saves, and the quality does not decrease with each save. As you suggest, MP3s are not directly editable by any application I know of -- instead, you edit a copy of the waveform described in the MP3 file. Thus, there's no loss of quality. -- David W. Fentonhttp://dfenton.com David Fenton Associates http://dfenton.com/DFA/ ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing
On 13 Feb 2009 at 17:25, Darcy James Argue wrote: Here's what I understood you to be suggesting: 1) Open the MP3 in Audacity and up-sample it to WAV. Save the WAV version. If by upsample to WAV you mean the same process that happens when the MP3 is played, then, sure. 2) Make the edits in Audacity on the WAV version, then and re-encode for MP3. Instead, my first suggestion would be to use an editing application that operates on the original MP3 file and does not require you to re- encode -- which, as far as I know, is what is happening with the app I use (Fission). That would allow you to avoid having to re-encode the MP3, which causes more degradation than editing the MP3 directly. I think that others are right to say that you can't work on the original MP3, only on a copy of the waveform described by the MP3. This is actually what happens with JPGs, too -- when you load a JPG, it is uncompressed into memory as a bitmap, because that's what can be displayed onscreen. Any time you view a JPG, it is uncompressed into a bitmap. When you're editing the JPG, you're editing the expanded bitmap, and when you save it, it is compressed for writing to the JPG file. I see this as pretty much analogous to how MP3s work, though I don't have any apps that will edit an MP3 directly (like all graphics programs edit JPGs directly). Failing that: assuming David is correct that Audacity has its own native format, then Step 1 above seems unnecessary. Just open the MP3 in Audacity, make the edit, then save back to MP3. It's not a matter of opening it in Audacity -- the only files Audacity can *open* are its own. Any other format you import into Audacity, which means the waveform described by the file you're importing is saved in Audacity's format (that describes the uncompressed waveform). -- David W. Fentonhttp://dfenton.com David Fenton Associates http://dfenton.com/DFA/ ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing
On 13 Feb 2009 at 18:05, Aaron Sherber wrote: Keeping in mind that every save to MP3 format degrades quality, what you want to avoid is open the MP3, make an edit, save back to MP3. Open the new MP3 a week later, make some more edits, save back to MP3. Repeat again the next day. You've now re-saved as MP3 3 times, introducing more artifacts along the way. If you open the MP3 and save your intermediate work each time as a WAV, you incur no further loss penalty until you're done and you convert your WAV to MP3 to share with others. I don't think this is correct, Aaron. When you edit the MP3, you aren't editing the original data, but a waveform that is result of expanding the data from the MP3 file. If you save that waveform to exactly the same bitrate as the original source MP3, you won't lose anything that was not already missing in the original MP3. Now, you may get artifacts if you use a different codec, but that's entirely a different issue. And, of course, if you encode to a lower bitrate, you'll lose quality. But that's not because of the conversion process but because you've picked a lower bitrate! Now, in the other direction, you could save a new MP3 from the waveform loaded into memory and choose a higher bitrate than the original source MP3 file, but you won't get any better quality than the original MP3 -- you can't create information that's not there. (It's the same with images. If someone sends you a JPG that you plan to edit repeatedly, you should first open it and save it as a TIF, and then make all your edits to the TIF. When you're done editing, you can export the TIF as a JPG for portability, keeping your source TIF for any further changes. If you edit and save as JPG, you incur loss and introduce artifacts each time.) As I said in another post, I think this is incorrect, also. -- David W. Fentonhttp://dfenton.com David Fenton Associates http://dfenton.com/DFA/ ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing
I'm going to preface all of this by saying that I'm always happy to be proved wrong in things like this. On 2/13/2009 7:22 PM, David W. Fenton wrote: The usual method is to have, say, a 15% compression ratio. When you open a file, your graphics editing progam knows what the compression ratio that it was saved at is, I don't believe that's true. Neither Paint Shop Pro nor GIMP appear to display this information; I suppose they may know it internally, but this is the first I've heard this assertion. Actually, look at http://photo.net/learn/jpeg/#ijg . It discusses a utility which allows the *estimation* of the quality settings for any given JPG. It also says It would be most useful for Jpeg writing software to list the prior quality level so you could rewrite (if necessary) at the same level. I do lots of graphics editing and while I keep TIFs as my source files, I do lots of editing in JPGs once the graphic has reaced a certain point in the editing process. And that includes multiple edits and multiple saves, and the quality does not decrease with each save. Well, see http://www.faqs.org/faqs/jpeg-faq/part1/section-10.html , which would seem to disagree with you. They do say that relatively little further degradation occurs, but that's not the same as no change in quality. Aaron. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing
On 2/13/2009 7:37 PM, David W. Fenton wrote: I don't think this is correct, Aaron. When you edit the MP3, you aren't editing the original data, but a waveform that is result of expanding the data from the MP3 file. If you save that waveform to exactly the same bitrate as the original source MP3, you won't lose anything that was not already missing in the original MP3. I really don't think the latter part of this is true. I think the waveform will include some data which is interpolated from the lossy MP3. When you then save again to MP3, those interpolations are themselves subject to lossy compression -- they're not just recognized as interpolations and tossed out somehow. As always, this is only the opinion of a reasonably experience layman. If anyone has links to contradictory information, please share. Aaron. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing
On 13 Feb 2009 at 19:37, Aaron Sherber wrote: I'm going to preface all of this by saying that I'm always happy to be proved wrong in things like this. On 2/13/2009 7:22 PM, David W. Fenton wrote: The usual method is to have, say, a 15% compression ratio. When you open a file, your graphics editing progam knows what the compression ratio that it was saved at is, I don't believe that's true. Neither Paint Shop Pro nor GIMP appear to display this information; They don't display the information, but PSP, at least (which is what I use for all my graphics editing -- I can't stand the GIMP), does not continue to compress the file beyond its current compression ration. That is, continued saves do not lessen the quality of the JPG. I suppose they may know it internally, but this is the first I've heard this assertion. Try it in PSP. I just took a file and saved it 6 times with compression set at 15%. When I compare the version saved 6 times to the original it is absolutely indistinguishable. This shows that the compression ratio is not additive (well, technically, multiplicative). Actually, look at http://photo.net/learn/jpeg/#ijg . It discusses a utility which allows the *estimation* of the quality settings for any given JPG. It also says It would be most useful for Jpeg writing software to list the prior quality level so you could rewrite (if necessary) at the same level. Perhaps you're right. But when you open a JPG for editing, you've unpacked it to a bitmap. If the original file was compressed 15%, the bitmap you're viewing is *not* compressed -- it's a full bitmap, with all colors and pixels intact to paint the image onscreen. The compression takes the information in the bitmap and saves it with 15% compression -- there is no loss of information in this process, because (as with a WAV file that is created from an MP3) you're working with a non-compressed file. It's only the save process that discards data, and if you're saving back to the same compression ratio as the source file, you won't see any difference at all. I do lots of graphics editing and while I keep TIFs as my source files, I do lots of editing in JPGs once the graphic has reaced a certain point in the editing process. And that includes multiple edits and multiple saves, and the quality does not decrease with each save. Well, see http://www.faqs.org/faqs/jpeg-faq/part1/section-10.html , which would seem to disagree with you. They do say that relatively little further degradation occurs, but that's not the same as no change in quality. It says that if you're saving at the same ratio, any loss is very tiny. My experience says that for all practical purposes, there is no loss. I do note that the JPGs that I saved don't have the same file size: 46,702 1.jpg 46,808 2.jpg 46,812 3.jpg 46,806 4.jpg 46,809 5.jpg 46,806 6.jpg It's interesting to me that each subsequent save does not make the file smaller. Indeed, the first save made it larger! But the differences are so tiny that I can't see how any loss could actually be visible in the image. Of course, I didn't actually do any edits, just saved the file. I think your concerns are overblown. Certainly the article is mixing different issues, given that one example it gives is JPG-GIF-JPG. Of *course* that's going to degrade the image, because of remapping the larger color space onto the smaller color space. But that's a completely different issue from maintaining the same file format and the same compression ratio. All that said, I mostly don't do multiple generations of edits in JPG. I tend to take a source TIF, crop and rotate, resize, sharpen, edit (if needed, e.g., gamma correct) and then save as JPG. If I need to make a thumbnail, I won't start over from the source TIF, but use the saved JPG, because I'm discarding a lot of data just in sizing it down to a thumbnail. So, I guess in practice I don't violate your rule, as once I've saved as JPG, I don't do much editing (except perhaps to alter color, or contrast or gamma or properties like that), other than relatively minor adjustments to the image. -- David W. Fentonhttp://dfenton.com David Fenton Associates http://dfenton.com/DFA/ ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing
Useful for making ringtones, I suppose! I have had a lot of good luck on the Mac with Sound Studioespecially with its liberal demo mode. noel jones On Feb 13, 2009, at 6:23 PM, Darcy James Argue wrote: iTunes lets you make volume adjustments and change the start and stop time. File - Info - Options. But these don't get written into the file itself, I don't think. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing
On 2/13/2009 8:08 PM, David W. Fenton wrote: They don't display the information, but PSP, at least (which is what I use for all my graphics editing -- I can't stand the GIMP), does not continue to compress the file beyond its current compression ration. Except that I don't think PSP has any way of actually determining a file's current compression ratio. Try it in PSP. I just took a file and saved it 6 times with compression set at 15%. When I compare the version saved 6 times to the original it is absolutely indistinguishable. Were you closing and opening the file, or just hitting Save 6 times? The latter won't do anything, because each time you hit Save, PSP just compresses and writes out the bitmap it has in memory. And in the former case, the sources I have read do say that saving in the same app with the same compression ratio produces virtually no artifacts. And that artifacts would really only appear in areas you've edited, so that repeated opening and saving wouldn't be expected to show any degradation. But this whole conversation has been about editing files. It's only the save process that discards data, and if you're saving back to the same compression ratio as the source file, you won't see any difference at all. If you're saving back with the same application, at the same compression ratio, with no edits, then I suppose you're right. It says that if you're saving at the same ratio, any loss is very tiny. My experience says that for all practical purposes, there is no loss. I'm not disagreeing with you here. But practical purposes vary from user to user. The fact is that there *is* further loss, and the loss may be noticeable depending on the size of the source file, the compression ratio applied, and the users' eye. I do note that the JPGs that I saved don't have the same file size: Well, that in itself indicates that the files are not *strictly* identical. Of course, I didn't actually do any edits, just saved the file. Right. And as the articles point out, edited areas of the photo will show greater loss. I think your concerns are overblown. Quite possibly. I'm just pointing out guidelines for best and safest practice: Always save your master in a non-lossy format. Aaron. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing
On 13 Feb 2009 at 20:36, Aaron Sherber wrote: On 2/13/2009 8:08 PM, David W. Fenton wrote: They don't display the information, but PSP, at least (which is what I use for all my graphics editing -- I can't stand the GIMP), does not continue to compress the file beyond its current compression ration. Except that I don't think PSP has any way of actually determining a file's current compression ratio. It doesn't actually need to. Once the file is open, it's an uncompressed bitmap, with 100% of the information that the original file contains. As long as the save uses the same compression ratio, the result should be, for all intents and purposes, identical. Try it in PSP. I just took a file and saved it 6 times with compression set at 15%. When I compare the version saved 6 times to the original it is absolutely indistinguishable. Were you closing and opening the file, or just hitting Save 6 times? I opened a JPG. I saved it under a new name. I closed it and opened the new file. I then saved it under a new name, closed it and opened it again. And so forth. [] I do note that the JPGs that I saved don't have the same file size: Well, that in itself indicates that the files are not *strictly* identical. But the difference is a few bytes, a tiny percentage of the whole datastream, which means there can't possibly be any *visible* difference. -- David W. Fentonhttp://dfenton.com David Fenton Associates http://dfenton.com/DFA/ ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
RE: [Finale] Editing
(It's the same with images. If someone sends you a JPG that you plan to edit repeatedly, you should first open it and save it as a TIF, and then make all your edits to the TIF. When you're done editing, you can export the TIF as a JPG for portability, keeping your source TIF for any further changes. If you edit and save as JPG, you incur loss and introduce artifacts each time.) As I said in another post, I think this is incorrect, also. David Fenton I have heard the first theory and decided to test it. I opened a high resolution photo in Photoshop and saved it with the maximum compression as a jpg. Then reopened it and saved again with maximum compression. After repeating this seven times I can see no further degradation after the first compression. The file size remains exactly the same also. David Fenton appears to be right. (I have no idea if this applies to mp3s, though.) RY ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing
On 2/13/2009 9:12 PM, David W. Fenton wrote: It doesn't actually need to. Once the file is open, it's an uncompressed bitmap, with 100% of the information that the original file contains. As long as the save uses the same compression ratio, the result should be, for all intents and purposes, identical. Yes -- for all intents and purposes. But the difference is a few bytes, a tiny percentage of the whole datastream, which means there can't possibly be any *visible* difference. First, let me say that in general, I agree with you here. However, this thread has been all about lossy compression in the context of file *editing*. If you edit a JPG in any non-trivial way (and I don't know offhand exactly what that definition is) and save it again as a JPG, the changed parts of the photo will be subject to recompression, possibly resulting in visible artifacts. Also -- and I admit this isn't particularly relevant here -- comparing file sizes isn't really an adequate way of comparing the files. You're saying that because one file is only a few bytes bigger or smaller, there can't be much difference between the two. But of course, even if the two JPGs were exactly the same size, the actual data could be wildly different. Aaron. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing
On 2/13/2009 8:29 PM, Richard Yates wrote: I have heard the first theory and decided to test it. I opened a high resolution photo in Photoshop and saved it with the maximum compression as a jpg. Then reopened it and saved again with maximum compression. After repeating this seven times I can see no further degradation after the first compression. The file size remains exactly the same also. Yes. If a JPG is opened and saved, with no editing, by the same application, at the same compression ratio, you will likely see no visible degradation. But the thrust of this discussion has assumed that there is editing going on. If you make edits to the JPG and save it again, the parts which were edited will be recompressed and degraded in a way which may or may not be visible. Aaron. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing
On 13 Feb 2009 at 23:27, Aaron Sherber wrote: Also -- and I admit this isn't particularly relevant here -- comparing file sizes isn't really an adequate way of comparing the files. You're saying that because one file is only a few bytes bigger or smaller, there can't be much difference between the two. But of course, even if the two JPGs were exactly the same size, the actual data could be wildly different. But I actually *looked* at the files. I maximized the window I was viewing them in, opened all 6, and flipped through them. This meant that they were appearing all in exactly the same location onscreen, pixel for pixel, so that any differences in even a few pixels would have jumped out. There was no visible difference between the files. None whatsoever. -- David W. Fentonhttp://dfenton.com David Fenton Associates http://dfenton.com/DFA/ ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
RE: [Finale] Editing
On 13 Feb 2009 at 23:27, Aaron Sherber wrote: Also -- and I admit this isn't particularly relevant here -- comparing file sizes isn't really an adequate way of comparing the files. You're saying that because one file is only a few bytes bigger or smaller, there can't be much difference between the two. But of course, even if the two JPGs were exactly the same size, the actual data could be wildly different. But I actually *looked* at the files. I maximized the window I was viewing them in, opened all 6, and flipped through them. This meant that they were appearing all in exactly the same location onscreen, pixel for pixel, so that any differences in even a few pixels would have jumped out. There was no visible difference between the files. None whatsoever. -- David W. Fentonhttp://dfenton.com I did it again with edits (fairly small, e.g. non-clipping, adjustments to brightness, contrast, hue, and saturation) that I reversed on the next pass and did get successive degradation. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing an expression in FinMac 2008
Um, it is probably covered in the manual? There is a menu called TEXT that appears in the menu bar. On Tue, Sep 9, 2008 at 9:29 AM, mystrom1 [EMAIL PROTECTED] wrote: How do I change a font (and font size) for an expression created in the expression tool? I want to create a fermata in the expression tool using a U and maestro font, 24 point. I can create the U in the expression tool, I just don't see anywhere in the edit box to change the font or font size. Thanks, Martin ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing an expression in FinMac 2008
Thanks... And, UM, I coulda done without the sarcasm. That was really not necessary! On Tue, Sep 9, 2008 at 12:42 PM, Eric Dannewitz [EMAIL PROTECTED]wrote: Um, it is probably covered in the manual? There is a menu called TEXT that appears in the menu bar. On Tue, Sep 9, 2008 at 9:29 AM, mystrom1 [EMAIL PROTECTED] wrote: How do I change a font (and font size) for an expression created in the expression tool? I want to create a fermata in the expression tool using a U and maestro font, 24 point. I can create the U in the expression tool, I just don't see anywhere in the edit box to change the font or font size. Thanks, Martin ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing an expression in FinMac 2008
Then maybe consult the manual before posting? It's pretty obvious how to do what you were asking to do...the Finale manual is a great reference (one of the best software manuals). On Tue, Sep 9, 2008 at 10:02 AM, mystrom1 [EMAIL PROTECTED] wrote: Thanks... And, UM, I coulda done without the sarcasm. That was really not necessary! On Tue, Sep 9, 2008 at 12:42 PM, Eric Dannewitz [EMAIL PROTECTED] wrote: Um, it is probably covered in the manual? There is a menu called TEXT that appears in the menu bar. On Tue, Sep 9, 2008 at 9:29 AM, mystrom1 [EMAIL PROTECTED] wrote: How do I change a font (and font size) for an expression created in the expression tool? I want to create a fermata in the expression tool using a U and maestro font, 24 point. I can create the U in the expression tool, I just don't see anywhere in the edit box to change the font or font size. Thanks, Martin ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing an expression in FinMac 2008
What is obvious to you may not be obvious to someone else. I will refrain from commenting further. On Tue, Sep 9, 2008 at 1:17 PM, Eric Dannewitz [EMAIL PROTECTED]wrote: Then maybe consult the manual before posting? It's pretty obvious how to do what you were asking to do...the Finale manual is a great reference (one of the best software manuals). On Tue, Sep 9, 2008 at 10:02 AM, mystrom1 [EMAIL PROTECTED] wrote: Thanks... And, UM, I coulda done without the sarcasm. That was really not necessary! On Tue, Sep 9, 2008 at 12:42 PM, Eric Dannewitz [EMAIL PROTECTED] wrote: Um, it is probably covered in the manual? There is a menu called TEXT that appears in the menu bar. On Tue, Sep 9, 2008 at 9:29 AM, mystrom1 [EMAIL PROTECTED] wrote: How do I change a font (and font size) for an expression created in the expression tool? I want to create a fermata in the expression tool using a U and maestro font, 24 point. I can create the U in the expression tool, I just don't see anywhere in the edit box to change the font or font size. Thanks, Martin ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing an expression in FinMac 2008
On 9 Sep 2008 at 14:08, mystrom1 wrote: What is obvious to you may not be obvious to someone else. I will refrain from commenting further. Even *I* didn't find Eric's remark sarcastic or inappropriate. On the other hand, sometimes one does look in the manual, but for whatever reason, ends up looking in the wrong place, and doesn't find the answer. In that case, it would be helpful to say I looked in the manual under ... but couldn't find anything. At least then we know you're *trying*, as opposed to just being lazy. -- David W. Fentonhttp://dfenton.com David Fenton Associates http://dfenton.com/DFA/ ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing old file in FinMac2006, can't change system bottom margins
Could be several places to find the fix: First, look at your default page setup. Check and see if the systems in question are optimized; sometimes Un-optimizing then re-optimizing wakes up something in the software and it might correct. Another is redefine all pages if the other things aren't working. As a final attempt, you can make sure all your page setup items are what you want, do a Save As so you can always go back to the original file. Then, (this was a Coda (when they were still Coda) solution years ago), Group all the staves as 1 New Group (you can delete it later in the new doc you create), then Extract Parts (SELECTING ONLY the new group you just created). Coda told me this is one way to clean out junky data that may be causing a doc to behave badly. When you open the newly created (extracted) part, you can delete the group you just created and if you still see the goofy margin issues, I don't know what else to suggest that you would want to hear about (ie: re-doing the score, which I have had to do only a couple of times over the years because of a badly corrupted file.) I went straight from 2002b to 2006d, so I've had some issues with midi and playback problems (sometimes a stave or two ignores Hairpings dynamics, expressions, etc) which has given me some serious heartburn, but I have usually been able to fix the problem (usually by creating a new staff and copying ONLY the entries and NOT the Performance/Continuous data info). This only seems to happen when I open the older doc with the newer version, and the older version was set up for midi playback, not using NI/Garritan samples. I've got a strange problem. I have edited a file from 2002 in FinMac 2006c, and I am at the very end of the operation, laying out the score. I can't change the bottom system margins of any system in the score. They are all set to zero, according to the window, but the bottom right handle is about 1.75 inches below the lowest system and obstinately refuses to be raised any more. It is exactly as if there are two extra staves that I can't see, but I can't find any tool that recognises that there are more than seven staves (what I can see.) File Maintenance finds no problems with the integrity of the doc, and Sort or Respace does nothing. I know if all else fails I can copy the contents to a new file and most likely the bug will not be copied to the new file, but that is a lot of work considering I am in the home stretch. Any ideas? I seem to be the only one this happens to. Or maybe I just edit old files a lot, so it happens more. Christopher ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] Editing old file in FinMac2006, can't change system bottom margins
On Feb 11, 2007, at 8:03 PM, Christopher Smith wrote: I've got a strange problem. I have edited a file from 2002 in FinMac 2006c, and I am at the very end of the operation, laying out the score. I can't change the bottom system margins of any system in the score. They are all set to zero, according to the window, but the bottom right handle is about 1.75 inches below the lowest system and obstinately refuses to be raised any more. It is exactly as if there are two extra staves that I can't see, but I can't find any tool that recognises that there are more than seven staves (what I can see.) File Maintenance finds no problems with the integrity of the doc, and Sort or Respace does nothing. I solved it. Redefine Pages did it. Apparently, because I had resized the staves using the Zoom Tool after turning off the zoom in Page Size, the document thought that the systems were still the old sizes. Weird. Thanks anyway to those who I know were working on this. 8-) Christopher ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
RE: [Finale] editing question
Andrew, Given the keysig, is there any evidence that the composer had originally spelled that chord as Fb but decided to simplify to E later? (I'm assuming that you're working off a manuscript) If so, the F in Bsn II could have the flat missing...possible?? Jim From: [EMAIL PROTECTED] on behalf of Andrew Stiller Sent: Thu 08-Dec-05 12:34 To: finale@shsu.edu Subject: [Finale] editing question Big symphony, 1953. Winds in threes. Lots of bitonal harmonies. In a near-tutti (trps, hns, timp resting) with everybody playing an E-minor chord (the key sig. is Gb), the 2d bassoon, and only the second bassoon, has an F (natural), sustained across 2 bars. Is this an error? (FWIW, bn. 1 bcl have G natural a 9th higher; cb, vc, btrb, tuba have melody Bn En Dn Bn An Gn). Andrew Stiller Kallisti Music Press http://home.netcom.com/~kallisti/ ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale winmail.dat___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] editing question
Andrew, Given the keysig, is there any evidence that the composer had originally spelled that chord as Fb but decided to simplify to E later? (I'm assuming that you're working off a manuscript) If so, the F in Bsn II could have the flat missing...possible?? Jim Nice theory, but this composer (Lejaren Hiller) just likes being harmonically perverse. He even writes atonal stuff with key signatures--and in remote keys, too. As you might imagine, he tends to have lots of accidental and transposition errors, wh. is what made me question this note in the first place. Anyway, after posting my query, I found the answer, since it turns out the trombones reinforce the bn-2 note toward the end of the two measures--so what it's supposed to be is a minor harmonic irritant that later becomes a prominent part of the chord. --Andrew ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
RE: [Finale] editing question
Ah, there's the rub, Andrew... Since I have NO acquaintance with perversion of any kind, since it is SUCH a foreign concept to me, such a thought would never have crossed my mind. ;-) But it was a good guess ;-) Saint Jim From: [EMAIL PROTECTED] on behalf of Andrew Stiller Sent: Thu 08-Dec-05 17:21 To: finale@shsu.edu Subject: Re: [Finale] editing question Andrew, Given the keysig, is there any evidence that the composer had originally spelled that chord as Fb but decided to simplify to E later? (I'm assuming that you're working off a manuscript) If so, the F in Bsn II could have the flat missing...possible?? Jim Nice theory, but this composer (Lejaren Hiller) just likes being harmonically perverse. He even writes atonal stuff with key signatures--and in remote keys, too. As you might imagine, he tends to have lots of accidental and transposition errors, wh. is what made me question this note in the first place. Anyway, after posting my query, I found the answer, since it turns out the trombones reinforce the bn-2 note toward the end of the two measures--so what it's supposed to be is a minor harmonic irritant that later becomes a prominent part of the chord. --Andrew ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale winmail.dat___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] editing score and parts
John Howell wrote: At 4:04 PM -0500 3/19/05, dhbailey wrote: There is a way to do what you want, it's just that Finale programmers haven't figured out how to do it. :-( My bet is the first notation software which does that (Sibelius, Finale or the newly developping Notion software from http://www.notionmusic.com which may give these two giants a run for their money) first will eventually be the last engraving software standing. It will be such a huge time-saver that everybody using anything else will jump ship and begin using that program. Sadly, not at all the case. Composer's Mosaic did exactly this, automatically and instantaneously, from the very beginning. The key may have been that score and parts are all part of the same file. The downside, of course, is that a mistake entered in EITHER score or parts is instantly transferred to the other, so checking the score for an error in the parts is a waste of time. But MotU seem no longer to be supporting Mosaic, despite this ability. My son-in-law was smart enough to get it operable for me in OSX Classic, so I can (for the moment) still access hundreds of my scores, but soon I'll inevitably lose them. Dennis' fear of losing access to Finale is NOT paranoid! john Good point -- Composer's Mosaic was before it's time, unfortunately, when not nearly as many composers were as computer-savvy as they are today and there was still much hand-copying being done. As for Dennis' fear of losing access to Finale, I agree, it's not paranoid. But copy protection isn't what has done Mosaic in, it's the advancing OS which has left the old code in the dust and the developper of Mosaic decided to pull the plug on the program. Nothing will be able to save Finale into the future once either Windows or MacOS move onto 128-bit programming and the then-current versions won't run any 16-bit apps anymore. That could happen to open-source freeware as easily as to corporate-developped expensive software. It's good your son-in-law got Mosaic working for you -- go about saving them all as midi files so you can import them into Finale, as well as making certain you have printed versions of them all. You might even consider printing them to PDF files so you'll have electronic versions rather than paper versions. As I recall, also, Composer's Mosaic was a Mac program, not a Windows program, which cut out a huge potential market, another factor contributing to it's downfall. -- David H. Bailey [EMAIL PROTECTED] ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] editing score and parts
David Bailey wrote: As for Dennis' fear of losing access to Finale, I agree, it's not paranoid. If Dennis's fear was losing access to data in files created with Sibelius, I would agree that it would not be paranoid. However, at least the ~.etf file format of Finale is open, and anyone who wishes can create a notation program to read and write those files. For that reason, I do consider Dennis' concerns about losing access to data a bit paranoid. But copy protection isn't what has done Mosaic in, it's the advancing OS which has left the old code in the dust and the developper of Mosaic decided to pull the plug on the program. Nothing will be able to save Finale into the future once either Windows or MacOS move onto 128-bit programming and the then-current versions won't run any 16-bit apps anymore. It's hard to say whether this is a true statement or not. I suspect if Finale's products have been properly designed, while I can imagine some things might need re-working for the 128 bit programming environment, I suspect that most of Finale is already carefully written so that what will be required with a switch of environments will be to recompile the source code with a suitable 128 bit compiler, and the new OS will not know the difference. The 16-bit applications which will fail to run in a 128 bit environment are going to fall into two general categories: those for which the source code is no longer available, and thus which cannot be recompiled, on one hand, and on the other, those that make illegal direct access calls to the hardware on the other. That could happen to open-source freeware as easily as to corporate-developped expensive software. I doubt it will happen much to either one. Also, I would note that as long as the lowest level software, by which I refer to that embedded in hard drives and other media reading devices is capable of reading the media upon which the files are stored, it won't matter what bit the applications are in. If they can read the data, they can process it. The only thing which prevents my old fortran program (on IBM punch cards) from working in my PC, is the lack of a reader. I know the program works; I retyped it into a DOS fortran compiler years ago, the DOS compiler still runs in the MS-DOS prompt of Windows. If one is using a notation package which produces data files with a proprietary file structure format, and they won't tell you what it is, and don't have an option for storing in some open source means, be afraid. Even with the authentication system in place, there are multiple options for reading Finale files, as long as you've taken the time and effort to save them as ~.etf files. If you haven't, well, its about like your deciding to hand copy scores using an ink which faces in a short period of time, or copying onto high-acid paper. Your choice of materials is the problem, not the materials themselves. Makemusic makes the options available; they have not control over whether you choose to use them. ns ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] editing score and parts
On 22 Mar 2005 at 22:39, John Howell wrote: At 4:04 PM -0500 3/19/05, dhbailey wrote: There is a way to do what you want, it's just that Finale programmers haven't figured out how to do it. :-( My bet is the first notation software which does that (Sibelius, Finale or the newly developping Notion software from http://www.notionmusic.com which may give these two giants a run for their money) first will eventually be the last engraving software standing. It will be such a huge time-saver that everybody using anything else will jump ship and begin using that program. Sadly, not at all the case. Composer's Mosaic did exactly this, automatically and instantaneously, from the very beginning. The key may have been that score and parts are all part of the same file. The downside, of course, is that a mistake entered in EITHER score or parts is instantly transferred to the other, so checking the score for an error in the parts is a waste of time. I'm scratching my head here over exactly what the problem is with this potential circumstance (it's sounds ideal to *me*!), nor how it differs significantly from our present situation with Finale. Was it not just a few days ago that we all chortled over the musician in rehearsal who said it couldn't be a wrong note in the Finale-produced part because it was the same note in the Finale-produced score? And don't all of us attempt to minimize to the greatest degree possible any edits to the musical text that have to be done after the parts are extracted? Is it not the case that many people make the correction in the score, then copy the single system and paste it into the previously extracted part? Would this not duplicate in the part any errors entered into the score? Where's the problem here? To me, it's a completely desirable goal, one to be praised not feared. -- David W. Fentonhttp://www.bway.net/~dfenton David Fenton Associateshttp://www.bway.net/~dfassoc ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] editing score and parts
To my question: If one uses ~.etf as the primary storage format for Finale data files, one will not lose access to the data in the files. . .. David Fenton wrote How successful is the import of ETF files in these other programs? How usable are the programs themselves? Do they lack capabilities that Finale has? and I would note that at present I know of two programs that read (though none that write) ~.etf files: Sibelius, and Lilypond, with lilypond doing so through a filter that converts the ~.etf file to a ~.ly one. But the format of the data file is just an arrangement of the data. Since the file structure is public, there is no reason that one could not create a new program to convert the files; this is not possible with Sibelius, since the file strucutre is kept proprietary. The problem I have with these ETF-conversion discussions is that no 3rd parties and no conversion is necessary if MakeMusic would simply do something very, very simple and inexpensive, i.e., set up a key escrow. It's such a small thing that I can't understand why there could be any resistance to such a simple and inexpensive operation. I'd think it would also be quite a selling point in comparison to the competition. Ive been to the MakeMusic offices, personally, a couple of years ago. I saw a number of people in the offices, but I did not see anyone eating drinking. And I do not make any assumption from the fact that neither Allen Fisher, nor the other people I have had the occasion to contact over the years have not discussed eating or drinking in forming an opinion that they do not. By the same token, I can think of good reasons why there might in fact be a key escrow, and why MakeMusic would choose not to even publish the fact, much less use it as a selling point. ns ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] editing score and parts
On 23 Mar 2005 at 6:13, dhbailey wrote: As for Dennis' fear of losing access to Finale, I agree, it's not paranoid. But copy protection isn't what has done Mosaic in, it's the advancing OS which has left the old code in the dust and the developper of Mosaic decided to pull the plug on the program. Nothing will be able to save Finale into the future once either Windows or MacOS move onto 128-bit programming and the then-current versions won't run any 16-bit apps anymore. That could happen to open-source freeware as easily as to corporate-developped expensive software. Well, yes, it *could* happen, but it could only do so if these conditions were made: 1. there was no compiler available that could compile the old code base to run on the new platforms, AND 2. there was no way to recode certain features of the old code base into a version compatible on the OS. Neither of these things has much likelihood in the time frames we're are discussing here. Yes, it's quite likely if you wait 100 years behind the last release of the open source code base and the effort to compile for current computer programs. It's not very likely if it all takes place within the natural evolution of the software ecosystem. As you all my remember, I program Microsoft Access database applications. I started doing that with version 2.0 back in 1995-96 when the current version of Windows was just beginning the migration from Win3.x (16-bit) to Win95. The NT-based version of Windows was not very widely used, so I didn't worry about it. My 16-bit Access applications ran just fine on Win3.x. They ran even better on Win95. They even ran just fine and dandy with a small amount of permission tweaking on NT 3.51. When Access95 came out, Microsoft had replaced Access Basic with Visual Basic for Applications, and VBA was implemented in all the programs in the Microsoft Office Suite. The changes were minor. Here's an example of a common command and its replacement: DoCmd OpenForm frmMyForm was replaced by: DoCmd.OpenForm frmMyForm Access95 was designed to do those kinds of conversions for you automatically. Indeed, it converted almost everything. Just about the only things that didn't convert were any dependencies on Windows [16- bit] API calls (i.e., outside of Access). I had a couple of existing applications that extensively used 16-bit add-in controls for tabbed dialogs and multiselect listboxes. Access95 implemented both of those natively. Fortunately, one of these applications was being phased out (actually, the companies it was being used by, penny stock trading firms, were just going out of business with the rise of online trading), and the other was used by only a single individual. I never converted either of those apps. But they both still run on every version of Windows that has ever existed since the time they were written. That means Win3.x, Win95, Win98, WinME, NT 3.51, NT 4, Win2K and WinXP (I don't know if it would run on Win2K3 Server, since it has stricter security and might prohibit the installation of 16-bit OCX's; but that's not a workstation OS, though it can be used to host Windows Terminal Server; my bet is that the OCX's could actually be installed and would work). Now, at some point, should MS drop support for 16-bit OCX's (or on a larger scale, for any 16-bit applications), then I'd have to convert. I'd have to keep an older version of Access, since current versions can't convert Access 2 files, and I'd have to remove the OCX's and replace them with the native 32-bit controls. But it's not a big deal. The only reason I never did it for the one remaining user was that it's just easier to install the OCX's on her new PCs than it is to take the time to rip it all out and start over. However, actual conversion is something I can do very, very easily as long as I have the versions of the software that can convert the older files. For right now, this means Access97 (the last to convert from Access 2), as all current versions of Access can convert from Access97. For open-source code, the situation is similar, though at once much simpler and far more complex. One would need a compiler that can deal with the old code, but also would need to convert outside dependencies (like the 16-bit API calls in my old Access apps) on obsolete technologies. It is the fact of having the source code that makes it possible to do the conversion in circumstances where it would otherwise be impossible (absent emulators of the obsolete platforms). -- David W. Fentonhttp://www.bway.net/~dfenton David Fenton Associateshttp://www.bway.net/~dfassoc ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] editing score and parts
On 23 Mar 2005 at 14:51, Noel Stoutenburg wrote: To my question: If one uses ~.etf as the primary storage format for Finale data files, one will not lose access to the data in the files. . .. David Fenton wrote How successful is the import of ETF files in these other programs? How usable are the programs themselves? Do they lack capabilities that Finale has? and I would note that at present I know of two programs that read (though none that write) ~.etf files: Sibelius, and Lilypond, with lilypond doing so through a filter that converts the ~.etf file to a ~.ly one. But the format of the data file is just an arrangement of the data. Since the file structure is public, there is no reason that one could not create a new program to convert the files; this is not possible with Sibelius, since the file strucutre is kept proprietary. I'm not asking what is possible. I'm asking WHAT IS IN EXISTENCE right now. What is possible may never ever come to pass, yet you seem to be putting your money on the mere possibility. The problem I have with these ETF-conversion discussions is that no 3rd parties and no conversion is necessary if MakeMusic would simply do something very, very simple and inexpensive, i.e., set up a key escrow. It's such a small thing that I can't understand why there could be any resistance to such a simple and inexpensive operation. I'd think it would also be quite a selling point in comparison to the competition. Ive been to the MakeMusic offices, personally, a couple of years ago. I saw a number of people in the offices, but I did not see anyone eating drinking. And I do not make any assumption from the fact that neither Allen Fisher, nor the other people I have had the occasion to contact over the years have not discussed eating or drinking in forming an opinion that they do not. By the same token, I can think of good reasons why there might in fact be a key escrow, and why MakeMusic would choose not to even publish the fact, much less use it as a selling point. Given that it's hurting sales among their must loyal user base, they would be idiots to choose not to publicize it if it already existed. On another note, I'm not sure why you've chosen to revive this subject yet again. I don't see that you're adding anything new to the discussion at all, just repeating points you've attempted to make in the past. You're free to do that, but I don't see the point of doing so. -- David W. Fentonhttp://www.bway.net/~dfenton David Fenton Associateshttp://www.bway.net/~dfassoc ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] editing score and parts
John Howell wrote: But MotU seem no longer to be supporting Mosaic, despite this ability. My son-in-law was smart enough to get it operable for me in OSX Classic, so I can (for the moment) still access hundreds of my scores, but soon I'll inevitably lose them. Dennis' fear of losing access to Finale is NOT paranoid! If Dennis' fear was losing access to Sibelius, his fear would not be paranoid, as S~ keeps the data file structure proprietary information. Finale has made the data file structure open, which is why not only can S~ read ~.etf files, but they can be converted to Lilypond, as well. The ability of Finale to write ~.etf, and the fact that file structures are open, is why I consider Dennis' fear of losing access to the data in ~.etf files, to be, is if not paranoid, at least coming very close to it. If one uses ~.etf as the primary storage format for Finale data files, one will not lose access to the data in the files. As far as I can tell, neither Sibelius, nor the other competitors of Finale provide the same capability. ns ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] editing score and parts
Owain Sutton wrote: David W. Fenton wrote: Or they aren't even trying. I think Finale, with its unlinked templates and unlinked libaries, is terribly flawed at a basic conceptual level My bet is the first notation software which does that (Sibelius, Finale or the newly developping Notion software ... will eventually be the last engraving software standing. It will be such a huge time-saver that everybody using anything else will jump ship and begin using that program. Fully agreed - although I assume the emphatic suggestion of complete conversion refers to a select groups of 'engravers', rather than the wider field of users of notation software? I'm not so sure about that -- composers who write music which have scores and parts and use engraving software such as Finale or Sibelius will benefit from such a feature immensely, not just engravers. I know I am constantly going back to older works of mine and changing things -- it's a real pain to have to also change them in the parts. I think David's idea, if I understand it correctly, of a sort of expanded Special Part Extraction, whereby you turn that on for a selected staff (or group) and get the page layout exactly as you want it, complete with page turns, systems-per-page, everything, and then SAVE that setting uniquely for that staff or group so that every time you turn on special part extraction, those settings are called up and you're set to go with the page layout exactly as the previous time, and with different settings saved for EACH staff or group in a score, is a real winner of an idea! I think the only users of notation software who wouldn't benefit from such a feature would be those who only turn out lead-sheets or keyboard music, anything where parts are never extracted from the original. -- David H. Bailey [EMAIL PROTECTED] ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] editing score and parts
[EMAIL PROTECTED] wrote: I'm fairly sure that this is a daft question and that I know the answer already, anyway, here goes. I engraved the score and parts for a work which was recorded for CD today. During the recording session, the composer had second thoughts about a number of things, mainly articulations in the string parts. Now the daft question - is there any way of linking the score and extracted parts so that the changes I make in the score are reflected in the parts so that I don't have to re-extract them (I don't want to have to re-tweak them) There is a way to do what you want, it's just that Finale programmers haven't figured out how to do it. :-( David Fenton has waged a long battle for dynamically linking parts and scores, but so far it has fallen on deaf ears at MakeMusic. To be fair, there may not actually be a way to do it, but everything David has suggested has made sense, and it can be done with documents as diverse as spreadsheets, word-processors and graphics programs where you can change a single number on a spreadsheet and all the values are recalculated, any references in a word processor or a graphics program (or both) to any numbers on that spreadsheet are updated to reflect any such changes, the next time those documents are opened. I am confident there is a way to do what you want, but as I said, the Finale programmers haven't figured out how to do it yet. My bet is the first notation software which does that (Sibelius, Finale or the newly developping Notion software from http://www.notionmusic.com which may give these two giants a run for their money) first will eventually be the last engraving software standing. It will be such a huge time-saver that everybody using anything else will jump ship and begin using that program. -- David H. Bailey [EMAIL PROTECTED] ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] editing score and parts
On Sat, 19 Mar 2005 15:48:02 EST, [EMAIL PROTECTED] wrote: Is there any way of linking the score and extracted parts so that the changes I make in the score are reflected in the parts so that I don't have to re-extract them (I don't want to have to re-tweak them) The link isn't going to happen. However, rather than re-extract parts from the score it would probably be easier (depending on the breadth of the edits) to edit the score and the relevant parts independently rather than go through the whole extraction rigamarole again. -- Brad Beyenhof [EMAIL PROTECTED] my blog: http://augmentedfourth.blogspot.com Life would be so much easier if only (3/2)^12=(2/1)^7. ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] editing score and parts
On 19 Mar 2005 at 16:04, dhbailey wrote: [EMAIL PROTECTED] wrote: I'm fairly sure that this is a daft question and that I know the answer already, anyway, here goes. I engraved the score and parts for a work which was recorded for CD today. During the recording session, the composer had second thoughts about a number of things, mainly articulations in the string parts. Now the daft question - is there any way of linking the score and extracted parts so that the changes I make in the score are reflected in the parts so that I don't have to re-extract them (I don't want to have to re-tweak them) There is a way to do what you want, it's just that Finale programmers haven't figured out how to do it. :-( David Fenton has waged a long battle for dynamically linking parts and scores, but so far it has fallen on deaf ears at MakeMusic. To be fair, there may not actually be a way to do it, . . . Sure there is! Finale already keeps track of certain kinds of things that apply only to certain layouts (such as staff groups defined in scroll view vs. groups defined in page view), so it's really only the application of a concept common to any application that presents data drawn from a database: the presentation should be separate from the data insofar as that is possible. Now, Finale's file format is unquestionably a database, and a hierarchical one. It's only a matter (only, he said) of making sure that content and presentation are stored separately. Now, how mixed up content and layout happen to be in an Enigma database, I can't say. But there's no question that it's possible. It could probably even be done without changing the current file format by simply implementing sub-classing at the database level (or sub-/super-types, in DB terminology). . . . but everything David has suggested has made sense, and it can be done with documents as diverse as spreadsheets, word-processors and graphics programs where you can change a single number on a spreadsheet and all the values are recalculated, any references in a word processor or a graphics program (or both) to any numbers on that spreadsheet are updated to reflect any such changes, the next time those documents are opened. I am confident there is a way to do what you want, but as I said, the Finale programmers haven't figured out how to do it yet. Or they aren't even trying. I think Finale, with its unlinked templates and unlinked libaries, is terribly flawed at a basic conceptual level, and to get linked parts would probably require a rethinking of the whole application in its many parts. My bet is the first notation software which does that (Sibelius, Finale or the newly developping Notion software from http://www.notionmusic.com which may give these two giants a run for their money) first will eventually be the last engraving software standing. It will be such a huge time-saver that everybody using anything else will jump ship and begin using that program. Finale already offers something Special Part Extraction, but doesn't save layout settings for it separately from standard score layout. If it did that, we'd already be home free in regard to most of the benefits of linked parts (keep in mind that I don't advising linking independent part files back to a score file, but simply to make parts a different view of the same score). -- David W. Fentonhttp://www.bway.net/~dfenton David Fenton Associateshttp://www.bway.net/~dfassoc ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] editing score and parts
Thanks Christopher (and everyone else who has offered help with this), That sounds like an easier way than doing everything twice. I'll experiment with it and see if any problems appear. There are lots of articulations/bowings added but the notes themselves are unchanged, but the parts have been carefully tweaked to avoidpage turns/awkward rehearsal marksetc. Thanks again, Lawrence "þaes ofereode - þisses swa maeg"http://lawrenceyates.co.uk ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
Re: [Finale] editing score and parts
David W. Fenton wrote: Or they aren't even trying. I think Finale, with its unlinked templates and unlinked libaries, is terribly flawed at a basic conceptual level My bet is the first notation software which does that (Sibelius, Finale or the newly developping Notion software ... will eventually be the last engraving software standing. It will be such a huge time-saver that everybody using anything else will jump ship and begin using that program. Fully agreed - although I assume the emphatic suggestion of complete conversion refers to a select groups of 'engravers', rather than the wider field of users of notation software? ___ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
