Why you never need to optimize

[AndyR]

I've only used optimise once (after backing up), it had exactly the same effect you described. I restored my backup and have never used optimise since - I don't really need it, I tend to have only one song on the card at a time and I backup a LOT anyway !

[Ted]

From Roland:

Optimizing does not corrupt the data.  We optimize all the time.

These aren't the droids you're looking for.

https://www.youtube.com/watch?v=CnjaUoR15dU

[launched]

Back it up, format the card, restore it.

danger! danger!

I believe this should be done periodically whether you need to or not. I do it after every couple of songs - Used to have problems on occasion, but never after this strategy.

Meanwhile, I think all BR users could learn a lesson from this and try to remember to backup the memory card before doing a Song Optimize.

I've only used optimise once (after backing up), it had exactly the same effect you described. I restored my backup and have never used optimise since - I don't really need it, I tend to have only one song on the card at a time and I backup a LOT anyway !

The best way to do it in my opinion, Andrew and 64G's!!

I think everybody needs to get burnt once. Part of what I do for a living is disaster recovery - guess who the most common customer is? When someone loses the best song they ever wrote, it will then become important to back their shit up.

I can see this has happened to me, AndyR, Ted(Who has written a tutorial on why we should back up) and BB from what I know firsthand.

I definitely believe our technology should be brought up to snuff. A little experience needs to go with it, though.

To the non-backeruppers:

Please record and master a wonderful song on your BR. Something that you could never reproduce in a million years. Listen to it once and savor. Then use the SD card as a level for your coffee table. Feel the pain.

Yes, optimize your 3 minute redo's, but back your shit up...


Mark

[Ted]

To the non-backeruppers:

Please record and master a wonderful song on your BR. Something that you could never reproduce in a million years. Listen to it once and savor. Then use the SD card as a level for your coffee table. Feel the pain.

Beautiful.  I just added a new word to the glossary: DUMB

[launched]

Beautiful.  I just added a new word to the glossary: DUMB

Just caught it - well put.

[64Guitars]

Optimizing does not corrupt the data.  We optimize all the time.

It doesn't corrupt the song data (the actual chunks of audio that you've recorded). However, if the song optimize routine is buggy, it can corrupt the event table which points to all those chunks of song data and tells the BR which chunks to play and in what order. If the event table gets corrupted, the song will no longer play correctly even though all of the song data is still there and intact, and any further recording will make matters worse. If you backup at this point, format the card, then restore the backup, you'll probably be no further ahead because the backup includes the corrupt event table. That's why it's important to backup before you do a song optimize, while the event table is still intact.

The update improves how data is written to some types of SD memory cards that would otherwise give a write error.

If write errors occur during the song optimization process, the event table will very likely be corrupted and the song will play back scrambled. It's possible that the song optimize routine does not detect and/or correctly handle write errors. Since error-free writing cannot be guaranteed with any and all memory cards, Roland should ensure that the song optimize routine checks for errors and validates written data on every write, and can fully recover from any errors that might occur.

[Ted]

...it's important to backup before you do a song optimize, while the event table is still intact.

And that's what I didn't do. 

So I declare...

There's no point to optimizing. It's so unpredictable that you always need to prepare in advance for the likelihood that it will fail.  And when it does fail you'll need to restore immediately afterward.

There's so little to gain, and it's so easy to avoid.  I would recommend against ever using optimize, unless there's some bizarre situation where there is no other alternative. (Would you agree, 64G?)

Here's a scenario:

"My opus is taking up most of my SD card, and I can't master unless I can free up X MB."

Yeah.  Right.  My experience is that the Micro BR likes to have at least 6x the available space on the SD card than you'll need for the WAV file you think you'll be creating.  I doubt that optimizing could ever create enough space if your song is already that bloated with song data you actually need.  You could instead free up space by backing up the song, and erasing any v-tracks you won't be needing for your bounce or master.  You can only master or bounce up to four v-tracks a once--which means you can erase up to 28 v-tracks in this scenario.

If your song is so bloated that even four v-tracks are taking up the majority of your SD card, you've got a problem.  And your problem is called "The Boss Micro BR."

How about this scenario:

"A madman has taken my family hostage and is going to kill them one-by-one unless I optimize my song."

Okay. Maybe then.

I can't think of another scenario where there's no way around optimizing.  I'd like to know if anyone can.

If not, launched, and AndyR, have got it right.  And, as they say, it's easy enough to avoid ever needing to do it: One song at at time.

(I keep lots of little sketches on the Micro BR.  But when I settle down and start to produce a finished product, I put all those sketches on my computer for safekeeping.)


End of take-away lesson.  What follows is more chatter on posts in this topic.

If write errors occur during the song optimization process, the event table will very likely be corrupted and the song will play back scrambled.

That's not a symptom I've encountered. Nor have I heard of others encountering that problem. You? Although I did get a "radio static" (scrambled?) issue when trying to import a WAV file.

Since error-free writing cannot be guaranteed with any and all memory cards, Roland should ensure that the song optimize routine checks for errors and validates written data on every write, and can fully recover from any errors that might occur.

Well, maybe I'll pass that along to my new friends at Roland.

Allow me to quote an old Micro BR user who has learned from the School of Hard Knocks:

I won't ever optimize a song again unless I'm desperate and have no other options (at least until there's new firmware that explicitly fixes these problems).

[Wiley]

I had so many problems with Drive busy.  Someone said optimize  I have done that and it made no difference one way or the other. But I think I did figure out my drive busy problem.  I always just recorded over the track.  Now If I goof up I erase the track and then start over on that track. I hven't had a drive busy since.  Unless I have to many songs I am working on  LOL

[64Guitars]

There's no point to optimizing. It's so unpredictable that you always need to prepare in advance for the likelihood that it will fail.  And when it does fail you'll need to restore immediately afterward.

There's so little to gain, and it's so easy to avoid.  I would recommend against ever using optimize, unless there's some bizarre situation where there is no other alternative. (Would you agree, 64G?)

I think each user has to make his own risk assessment for each situation. If you've worked all day on a song that's really going well, then you should be backing up often anyway, regardless of whether you plan to optimize the song or not (especially if you've had card errors or song optimize problems before). Backups are easy to do and you can't afford to lose all that work. On the other hand, if you've been using the same memory card for a long time without ever seeing a card error and you've used song optimize several times before without any trouble, then the risk probably isn't very high, especially if the song you're working on isn't that important to you or you already have a fairly recent backup of it.

If you have one or more 1GB memory cards, you'll probably never have a need to optimize your songs. Just check the available space before you start a new song and make sure you have at least 150MB free. That should be enough to record a song and export it. If the song is going to be very complex or long, then allow for more free space. If you don't have enough free space for a new song, then it's time to backup the card and initialize it.

But some people might still be using the 128MB card that came with their Micro BR. In that case, song optimize might be necessary to complete a complex song. Of course, they'd be better off getting a 1GB card but, if they can't rush out and buy one right away and they're anxious to complete their song, then an optimize might be needed. As long as they backup first, I think it's safe to optimize.

In theory, a song with lots of edits, deletions, overwrites, etc. could start getting Drive Busy errors, making it impossible to continue. A song optimize might solve that problem (probably not, but it might be worth a try if you backup the card first).

You could instead free up space by backing up the song, and erasing any v-tracks you won't be needing for your bounce or master.  You can only master or bounce up to four v-tracks a once--which means you can erase up to 28 v-tracks in this scenario.

I don't have time to check right now but I suspect that erasing v-tracks won't free up any memory card space. If it did, you wouldn't be able to undo the erase. That's why the song optimize function exists. The BRs support "non-destructive editing" which means that nothing ever gets erased or over-written. For example, suppose you record a 3-minute track, then realize that you made a mistake in the middle. So you rewind to just before the mistake and punch-in to record over it, then punch out. Well, it would be reasonable to assume that the corrected recording overwrote the section containing the mistake. But what really happens is that you're making a completely separate recording in an empty area of the memory card. The BR then updates the event table so that it points to the first section of your original recording, then the new recording, then back to the original recording at the point where you punched out. When you press Play, it plays that sequence of song data as described in the event table and you don't hear the mistake. But the original data with the mistake is still there. If you press Undo, the BR just updates the event table again so that it points to the original data instead of the new data. If you press Undo again, it acts as a "Redo" instead by updating the event table once more to point to the new data for that section of the song. The actual data is never changed; just the pointers to it in the event table are changed. I believe the same thing happens when you erase a v-track. It just updates the event table so that it no longer points to that data. But the data is still on the card taking up space. If you press Undo, it updates the event table to once again point to that data so that the "erased" v-track will again be included in the song. All of this dead data accumulates until you optimize the song. After you optimize, you can no longer undo any previous edits; only your new edits from that point forward.

If write errors occur during the song optimization process, the event table will very likely be corrupted and the song will play back scrambled.

That's not a symptom I've encountered. Nor have I heard of others encountering that problem. You? Although I did get a "radio static" (scrambled?) issue when trying to import a WAV file.

I think you misunderstood what I meant by scrambled. I didn't mean that the sound is distorted in any way or has static. What I meant is that the various chunks of data get played back in the wrong order or at the wrong times. I believe that is what happened to you since you said that the tracks played backed out of sync by a couple of measures. Most likely, the event table was corrupted and no longer able to play back the song data chunks at the right times or in the right sequence on all tracks.


So, yes, I agree that you shouldn't use song optimize unless you need to. With a 1GB card, you should never need to optimize unless you start getting Drive Busy errors due to a lot of editing* (the resulting complexity of the event table slows down memory card access in a way that's somewhat like a badly-fragmented hard disk in your computer). With a 128MB card, you might need to optimize in order to complete your song.

* Actually, a song optimize probably won't solve the Drive Busy problem anyway since most of the event table complexity will probably still exist. The only sure way to solve this problem is to export each track of the song to a separate WAV file, then create a new song and import the WAV files back in to their individual tracks. That way, each track is stored as a single contiguous chunk of data instead of multiple small chunks, greatly simplifying the event table and speeding up card access.

[Greeny]

On the (very) few occasions when the 'Drive Busy' message has reared it's ugly head, I've re-recorded to last offending track, or pressed 'undo', or re-corded a little snippet somewhere and it seems to fix the problem. It's a bit hit and miss, but I haven't had to export everything or lose anything for a very long time....