I got the following private message today:



I replied with the following message:




My best guess is that someone is trying to patent some kind of similar playlist technology and he's trying to make sure that it didn't already exist before they pursue the patent. I hope that's true. It'd be really cool if one of my BBS posts resulted in one less irritating and frivolous software patent in the world.

There's an outside chance that he's looking for someone to sue over an existing patent. If that's the case, obviously he's looking in the wrong place because the product is long since dead and the company scattered to the four winds.

I'm suspecting the former.

Mr lawyer, if you see this, please post a follow up here and let us know what you're up to. If you're on the level, many of the original devlopers still post messages here and would be happy to help you.

Mr. Fabris,

Your instincts are correct. My inquiry relates to an irritating and frivolous patent.

Mr. Lawyer

Anyway, now that we're in the public forum, we can discuss it openly and there are lots of people here who could answer how it applies in relation to the empeg car.

My recollection is that it behaves the same way any program that opens a digital file behaves, whether it's a music file or a document or an image file. The code that opens the file simply checks to see whether or not the file is one that it can "play". If not, it doesn't try to open it.

Some systems do a more comprehensive check than others. Poor systems assume that you've supplied a good file and then crash in unusual ways if it's not good. Other systems just glance at the header, while others perform deep and detailed checks. It's all a question of degree, and it's based on whether the programmers think it's likely that the software will get fed a bad file or not.

When such systems detect that they've been fed a bad file, they can either just skip the file without complaining, or they can put up an error. The empeg car has two places where it might detect a non-playable file. The first is when the song is getting loaded onto the player, the second is when the file is played back by the player.

If I recall, the empeg car's loader software (called Emplode) will put up an error and refuse to copy the file onto the player if it detects a bad file. If a bad file somehow makes it past Emplode and onto the player, but the player itself can't play the file, the player will try to skip the file without showing any error screen.

Sometimes a file can be bad in ways that neither emplode nor the player can detect until it's too late. In those cases, the player software usually crashes, the player reboots, and the cycle repeats, and the player gets in an infinite-reboot-loop bug. This is a known issue that's documented here.

Please feel free to post any further questions.

I have distant recollections of Karmas putting tracks that they had problems with playing into a separate list you could browse when you wanted to tidy up the mess. Something in the troubleshooting menu, maybe.

That description should probably come out here in the interests of preventing someone from claiming re-inventing it too, if someone with a better memory than me can be a bit more exact about it...

Hugo

Yes, that's exactly what happens on Karma, although we invented that after 2000, which is old_empeg's cutoff date.

By September 2000 all we had was the car-player functionality, as tfabris just described: "obviously incorrect" files (ones whose filename extensions we don't claim to play) don't reach the player at all; files which "turn out to be incorrect", either when playback is first attempted (e.g. if it's been named something.mp3 but isn't actually in MP3 format), or in mid-playback (e.g. if there's corruption in the middle of the file) are skipped. There's some extra logic so that, if you're in repeat mode, and all the files in the running-order are bad, it doesn't just sit there in an infinite loop of skipping: it would just stop playback.

IMO, this should all have badly failed obviousness if someone tried to patent it. Plus, we didn't really invent it (except maybe the no-infinite-loop bit); PC-based media players such as Sonique were already doing just the same thing.

Peter

Thanks for the information.

Any chance that there would be some documentation of these features beyond what is in:

http://empeg.com/downloads/empeg_User_Guide.pdf

Mr. Lawyer

No. That's the kind of thing programmers build into software specifically so that you don't *have* to write documentation.

Let me put it another way: If the software tries to play an invalid file, then it is likely to crash. Preventing that from happening is called "bullet-proofing" in programmer-speak. The simplest way to bullet-proof an application against bad data is to skip over bad data.

You don't document bullet-proofing, you just *do* it. The better your application is bullet-proofed, the more reliable it is. You don't put into a manual "by the way, our application is bullet proofed against bad data". That'd be like a car owner's manual saying "the new 2008 Ford Compensator has an electrical system that no longer shorts out when you flip the switches in the wrong order".

I hope someone isn't trying to patent bullet-proofing. If they are, it's another illustration of everything that's wrong with software patents.

<tangent>
Well, if that's how you write the documentation, then no, it's not useful to add. However, IMHO as a programmer, you don't put into a manual "our application is bullet proofed against bad data," but you do put into the manual what your product does do (skips to the next track), especially if it's non-obvious, when it encounters bad data (corrupted, or non-music files).

A car owner's manual would certainly say "If you flip the switches in the wrong order, all switches are reset to the off position to prevent overloading the electrical system."
</tangent>

That said, not all documentation is end-user documentation. Internal specifications, or even the comments surrounding the code, if either are available, could satisfy the requirements.

Oh, good point about internal documentation.

Unlikely that a stranger off the internet is going to get his hands on any Empeg internal company documentation, but it's a good point.

Probably not in this case. The skipping behaviour (and even, at least once it's happened to someone once, the infinite-loop avoidance) are so obvious that there wouldn't have been a requirements document that said "Implement playlists in such a way that the player skips unplayable tracks" -- it would just have said "Implement playlists". Unfortunately for old_empeg, the only "document" that could prove we had this functionality by September 2000, would be the 2000-era firmware release itself.

Peter