Ferret Project Wiki Page
Welcome to the Ferret Project. The Ferret Project is a an attempt to do for Mac OS-X what Otter has done for Windows users; provide a useful tool for the management of large collections of old time radio shows.
While Ferret is going to provide functions similar to those in Otter, it is not going to be a simple clone. Quite a few significant changes and additions are planned. Also, the compiler I'm using is supposed to be able to produce executables not only for the Mac, but also for Windows and Linux platforms with only minor changes to the source code. If it is possible to produce a working version for Windows machines without a great deal of extra work, I'll probably release a version for Windows.
At the moment, Ferret is in the planning stages. I'm putting together a "wish list" of functions and features that myself and other OTR collectors would like to see in an OTR management program. So if you're a Macintosh OSX user who has been frustrated by the lack of software for your computer, now is the time to come up with your ideas.
You are welcome to leave your comments, questions and ideas here, or you can email them to me at email@example.com
More information can be found here: http://www.feetache.com then click on the link to the Ferret Project.
As time permits, I'll be updating this with more information about the planning process, what is going to be included in Ferret, etc.
I've posted a new database specification and an updated outline of functions proposed for the Ferret project at http://www.feetache.com If you've been to the website before, you may need to click the REFRESH button on your browser to re-load your cache.
Suggest "See" and "See Also" references. If, for example, people know a series by an incorrect name (but this name is consider in common use) you enter the name with a "See" reference pointing it to the correct title.
If, for example, someone was looking for Eddie Cantor in the Chas'N Sanborn hour you could make a "See Also" reference and point them to any other series Eddie Cantor may have hosted. Or under the series "See Also" Cantor, Eddie?
Another suggestion would be to code each record with a Genre field that would allow one to serach for all programs in a certain genre (Am sure exact classifying is a disputed art form).
Thanks for allowing my two bits!
Thanks a lot for the suggestion. I've noticed a lot of files floating around with "Also Known As" or AKAs with alternative titles. The database is going to provide space for information that there isn't room for in Otter, and allowing for alternate titles would be useful. One idea we've been bouncing around linking to an external database that would provide additional information specific to a series or an episode, sort of a super log file that contains info that isn't really necessary to tracking a collection, but which real fans would like to have, like producer, director, guest stars, etc.
I think the above is a great idea!!
And a genre tag would definitely be useful.
If you have any other suggestions, just let me know. It's a lot easier to define how the program should work now, before the actual coding starts, than it is to try to make modifications later on.
Its a little thing, but an annoying one. If the Otter Log is saved with an empty space after the title of the episode, it records that space as part of the title. Therefore, when you try to rename the title, it adds an extra space before the .mp3. It is very easy to ignore whitespace at the end of a line, but you have to put it in the program.
I've never noticed that before, but I haven't used the log functions of Otter much. Having that kind of thing pop up in a program is pretty common. Back when I was doing programming professionally I almost always added generic subroutines that stripped off extra spaces at the beginning or end of a data field.
I have only read and heard about what Otter can do so don't know what is missing that should be added to Ferret. I have wanted Otter for the Mac since I found out about it. I like the idea of a genre tag but we need a set of standardized genre to go with it.
There is always going to be some debate about genre, of course. Often it's pretty clear, sometimes not. I'd call Lum and Abner a comedy, but some people might consider it to be more of a humorous soap opera. As for Otter on the Mac, the "Frogger" version *will* run under the PC emulator. I run it on my new iMac with Ver. 7 of the emulator. The standard Defender version won't run properly at all. It crashes with memory errors constantly. Even the Frogger version will bomb out with memory errors after it's been running for some time, especially when working with folders that have large numbers of files in them. It is also very, very slow. I have the 1.8 ghz processor with 1 gig of RAM, with 512 Meg for the emulator, and it's extremely slow, especially when updating ID3 tags. *feet_ache*
How feasable is a report printing function which would allow one to print out lists by series, or title or performer (that would require searchability within the data),I like to look at things by date and call up a variety of programs from one year, month and/or day (say my birthday).
Printer support is definitely on the list! The lack of printing capabilities was always a pet peeve of mine with Otter.
I'm planning on expanding search capabilities as well. I'm not really fond of how Otter handles searches.
I'm currently working on defining the "wish list" and getting it into final form and hope to get it up on the website at feetache.com within a week or so. I realize that it's been taking a considerable amount of time just defining what the program is going to do, but back when I was studying data processing and programming in college our systems analysis instructor really drilled that into us. Every hour spent defining exactly what the program should do can save many hours in programming and debugging time later. *feet_ache*
Website had to get reverted back to last night and we lost some stuff. That includes the stuff you had added to the bottom of this page.
Advice wanted on how collections are stored
I'm starting to look at programming considerations as I go over the list of functions and other things for Ferret, and one major item is how people store their OTR collections. I was talking with my son the other night about the project and he questioned the need to have Ferret track files stored on removable media (CD/DVD, etc.). He believed that because hard drives prices are now so low, it would be reasonable to assume that collectors would have their entire collection stored on hard drives, and would use CD/DVD only for backups. Therefore there was no need for Ferret to have to deal with removable media except perhaps for copying files or restoring from archive backups.
I wonder if he may have a point there. I have my entire collection on HD, and use CD/DVD only for backup, and I know some other people who do it as well.
So does Ferret have to deal with removable media? Or do you think most collectors would store their files on HD only? It would probably save a great deal of programming time if Ferret did not have to deal with removable media. *feet_ache*
In my opinion, both hard drives and cds suck for long term storage. I've seen too many people lose everything when their hard drives give up the ghost. CDs aren't a permanent storage solution either, as they have a limited life span.
Thanks for the advice, menachem. I really like that idea; do an HD only version first just to get a working version going faster and add CD support after the first is debugged.
I hope people are backing up their stuff on a regular basis. I generally have at least 2 copies of everything on CD, and I try to remember to burn new copies of all my archive CDs/DVDs once a year because I've learned not to trust the things. When I switched to the Macintosh, I had to restore my collection from CD to the Mac's external HDs, and I found problems with a small number of discs, perhaps 5 or 10 out of several hundred. Fortunately I had other copies of the material, but if I hadn't been paranoid about backups, I would have lost some files on those discs. Interestingly enough, all of the failed discs were expensive, brand name discs, while I had no trouble with the generic, off-brand ones.
I've also learned the hard way to never, NEVER put a paste on label on a CD or DVD. The CDs I labeled are still readable, but they don't work in the iMac's slot drive! The tolerances on the drive are so tight that something rubs inside when I insert a CD with a label and the disc won't spin up. When I run across an old CD I did label, I have to copy it using my wife's old PC and burn a new copy
My biggest problem right now is time. I work 40+ hours a week, plus I build custom furniture and I'm in the middle of designing and building a complete suit of mission style furniture, so free time to work on Ferret is limited.
Thanks again. *feet_ache*
One thing in otter that could use a huge improvement is the importing and exporting of logs (to and from text files). The otter way is convoluted and kludgy, you have to highlight the log file in order to import it. You should be able to import and export log files, just be clicking on an option|icon|etc.
That's a good point. There are a few things in Otter that are unnecessarily awkward to work with, and the log files are one of them.
In conversations with Ben Kibbler, an interesting thing came up. There are some episodes where the time period is known, even if the exact date is unknown. Like if you know that a certain star or sponsor was only on the show for a certain time period.
Now that's an interesting point. I hadn't thought of that, but now that you mention it, I have a few series and individual episodes where the actual date is unknown, and I hadn't given any thought to how Ferret would handle shows that kind of situation. THat can be a problem with some syndicated shows that didn't have a specific broadcast date. I'm going to have to give some thought on how to handle that kind of thing.
In the extended log file (i.e. the master database that contains the series/episode data, not the user DB that tracks the user's collection) I'd planned on putting a date range in the listing such as broadcast between Jan 5, 1940 to June 6, 1943, with exact dates given for the episodes, but I hadn't given any thought on how to deal with episodes without 'hard' broadcast dates.
I'd toyed with the idea of using Java, but abandoned that and am going to stick with the original plan of using RealBasic for a variety of reasons. RB seems to be more stable, and it should be easier to port the program to other platforms. Since RB is relatively inexpensive as well, that means other people can tinker with the program more easily once the source code is made available.
And yes, the source code is going to be made available without charge. I don't want the program's users to end up stuck with something that doesn't grow and change to meet their needs if I lose interest in the thing and decide not to work with it any longer.
I got an email from otrWalter the other day with an interesting idea. He's been working on developing a massive on-line database that has the potential for containing enormous amounts of detailed information about OTR series and episodes. He thought it might be a good idea for Ferret to be able to link to this database. He envisions a system that would work like some music oriented MP3 management programs do which link to on-line databases to provide the user with additional information music, only in this case it would be OTR oriented.
I don't think I would include this in the version of Ferret that is currently under development (this first version is going to be difficult enough to code and debug), but I think it could be useful, even though Ferret's expanded database would contain a lot of the info the on-line db would have.
feet_ache March 28, 2005
Would chosing to include it or not affect you in any way? If not, I don't think you should even worry about it. Since the on-line database isn't even in existence now, it would be tough to write it into the program.
This is all very speculative at the moment, and would definitely be for a future version of the program. It would require some modifications to the datastructure to include a unique ID code to link to the external data source and, of course, code necessary to retrieve and display the data. This would be entirely optional, though.
It sounds like a good idea, but I have some serious questions about it. There's no guarantee that the database will ever come on-line, and even if it does, there is no guarantee it will continue to exist. Who's going to host it? who's going to update it? There are a whole host of questions here. It could also have a great deal of potential. Something to think about, anyway.
At the moment I'm struggling with the ID3 tags. I thought I could just pick up a module to do it, but all of the ones I've tested so far are questionable at best, so I'm cobbling together routines to handle that.
I wanted to include a function to play mp3 files from inside of Ferret and thought that was going to be difficult. Turns out to be one of the easiest parts of the program. RealBasic's methods for dealing with files includes a function that passes off mp3s to the QuickTime routines that actually play the file, so it's only taking a few lines of code to to do that, which pleased me enormously :)
there are many open source ID3 tagging programs. For one, check out
Thanks for the info. I just DLed the source code for libid and some other routines that I discovered thanks to the links you gave! :)