Yeah, that sounds like the iPod just can't read certain filenames. It will be easy to convert those to something safer.

Well the iPod does not read tags from the files, right? So just write the next directory level as the Album field in the database...

Even if I did modify the Album field (which would mess up the display for the Browse/Artist and Browse/Album), I don't see how you can do support more than 1 level of directories.

The order goes like this:

If you had a file like c:\mp3\the_artist\the_album1\disc1\01 - song.mp3, you could set {Composer} = MP3/, {Album} = the_artist/, and then what?

I don't know, but I bet it's possible.

Not using these fields it's not.

The correct way to do this would be to use the notes reader feature. It's more or less designed for creating semi-custom interfaces for the iPod.

Here's the gist of it:
-You have text files. These files contain a semi-fakey form of HTML. Basically, you can define links, titles, some very minor formatting, etc.
-Links can point to either other text files or to songs or playlists or whatever.

So you create a series of text files and link files and things in such a way as to provide the structure you want.

Here's a complete rundown of everything the notes format supports: http://developer.apple.com/hardware/ipod/ipodnotereader.pdf

It's more than enough to build any type of hierachial interface you like.

It even supports a "museum mode", where if you want that to be the *sole* interface to the thing, you can make it so. Not that most people would want that, but still...

Note that this will only work on newer iPods, running 2.0 software and up.

Hey Aero, any possibility of supporting the Play Counter plugin for syncing purposes? I can help with describing how the playcount works on the iPod's files in greater detail if needs be.

wow.....


thats awesome.


With that text browser you can make anything, including the playlists to go with them. Thats awesome.


That's about as close as we are gonna get to it. Unless apple releases a SDK for the ipod. THen we could do whatever we want.

It's a shame that it's only for the 2.0 firmware. I suppose foo_pod could make it available depending on the ipod's firmware. I'm very pleased with this plugin so far. A wonderful collaborative work which I will use many-a-time. Quick question - is there a way to select tracks to delete instead of deleting them from the playlist then syncing? Also, in the future it would be great if foo_pod would be able to edit the info of the songs via masstager.

Is that data stored in iPod_Control\iTunes\Play Counts?

I saw the posting for the Play Counter component, but I haven't downloaded it or done any more than just scan the forum. From the initial post, it looks like all it would take is some glue that reads the play count from the iPod, and writes some metadata tags in the iPod files.

I haven't done anything with non-iTunesDB file data so far, but I'll consider adding the Play Counter support. I'll hit you up for details when I'm ready to work on it!

Interesting - thanks for the info!

I actually had a passing thought about the Notes feature, since I remember reading about someone who is selling games that use it, but I had no idea that it could interface with the songs. I'm doubly surprised that there is actually official documentation for it!

I'm feeling inspired after reading that PDF file. Now I just need some spare time to do something with that inspiration!

Nope. The best way to delete songs from the iPod is to do the following:

1. Do the "Load iPod Songs to foo_pod Playlist" command from the foo_pod menu.
2. Delete and/or reorder the songs in the foo_pod playlist to your satisfaction.
3. Run "Sync Current Playlist" on the foo_pod playlist.

What you are doing is syncing the files that are already on the iPod, minus the ones you deleted. foo_pod will notice that songs are already on the iPod, and simply delete the ones that are no longer in the list.

This isn't the fastest operation in the world, but I have done some post-0.5 work that will speed this up considerably. My goal for 0.5.1 (or whatever the next version) is to optimize foo_pod's slowest parts.

Syncing in this case is slow mainly because it has to rebuild the whole database. I could provide a way (context menu item) to remove the individual songs without having to rebuild the database. I'll add it to my "features to add" list.



I'm not sure what you mean by having foo_pod edit the song info via masstagger. Could you provide a little more info about what you are asking?

sorry, perhaps I did not get something, but is there a way to copy songs from the ipod to the hd similar/equal to ephpod's?

Yay! Thanks Otto!

For example, yesterday I wanted to change the genre of a few bands on the ipod, loaded them into masstagger, and changed the field. But when I disconnected my ipod nothing was changed. I suppose I should've synced the playlist before disconnecting. I thought it was directly editing the songs/db on the ipod. I'll give it another try today

You should be able to access the iPod files just like any others in Foobar. For example, you can drag a file out of the playlist and drop it in a folder. Or right click and drag it to a folder.

That will simply copy the file with the same filename as on the iPod. foo_pod doesn't directly have any support for building directory structures, like Ephpod and what you are probably asking for. You might be able to use DiskWriter to create directories to your preference - I believe there is a null DiskWriter component that will just copy the file from one folder (the iPod) to another (your hard drive). I might be wrong about that, but it wouldn't be too difficult to create a little program that would just accept DiskWriter input and write it out to a file.

If no one has written such a program and you can't get it working some other way, let me know and I can whip something up.

Masstagger should work on the iPod files - if not, it really is a Masstagger problem.

One thing that might have happened is you updated the files on the iPod, but didn't touch your local hard drive's files, then did a sync. foo_pod will notice that the files don't match, and delete the out of sync files on the iPod and replace them with the hard drive versions (I don't check for the case where the iPod files are newer than the hard drive).

I would recommend that you update your local hard drive's files with Masstagger, *then* do a sync to transfer them to the iPod. Otherwise, you will lose any changes whenever you do a sync. foo_pod only currently supports a one way sync (computer to iPod) like iTunes, although I might look into doing full sync (ala a Palm PDA) at some point.

Okay, so instead of loading the foo_pod playlist, then masstagging, you're suggesting to use explorer to find the music folder in the ipod, then load into masstager and update those? I'm not sure if i have this right

No, that would be doing the same thing.

What you should do is modify the original files on your hard drive - the ones that you transferred to the iPod. Then when you sync them, the Masstagger'ed files will be sent to the iPod.

There is nothing wrong with running Masstagger on the iPod files (say in the foo_pod playlist), but like I said before, when you sync them with your local files, the local files will overwrite your changes.

I don't have the original files on my harddisk - they're only on the ipod. You're saying that I can use the masstagger on the foo_pod playlist, which isn't working for me, so I must be overlooking something terribly obvious

Huh. Well, it should work, because to Foobar, the iPod is just another hard drive. In fact, I just ran a quick test and it worked as expected.

I did the following:

1. Load iPod to foo_pod playlist
2. Selected a song from the foo_pod playlist, right clicked and selected Masstagger->Edit Tags
3. For my test, I just added a new tag, and clicked Run
4. Checked the file Properties and verified that the new tag was in the file, even after clicking Reload From File.
5. Disconnected the iPod, connected it, reloaded the foo_pod playlist, and verified that the tag was still there.

Are you getting any sort of error from Masstagger, or anything on the Foobar console?

That's interesting, I did the same exact thing as you laid out, but when I disconnect the ipod and reload the foo_pod playlist, the files are back to where they were. No error either. It's not a big deal though - I can always take the music off the ipod, retag, then resync.

Maybe you have foobar2000's database turned on, and you have failed to click "Reload info from files" after reloading the iPod songs into foobar2000?

Also, you say "the files are back where they are" - The files aren't supposed to move when using the masstagger? Only the tags are changed...

The database is disabled.


I don't remember saying this, and I never expected the files to move. Just tagged. I'll figure this out eventually, I feel as though I'm taking the thread too far off track.

Sorry, I should've been more specific. I meant the tags were back to where they were. From the foo_pod playlist I changed the genre of an album, disconnected the ipod, reconnected and reloaded the foo_pod playlist, and the tags were back to where they were before.

Edit: Odd, it's working now! Well, at least it works Sorry about the waste of posts.

Yeah, here's the gist of it:

When you sync, you have to do the following:

1. Read the Play Counts file off the iPod. This contains all the play counts and such since the last time you synched. Everything "new" in other words. There's a class I wrote at the bottom of the iPodDB stuff specifically for parsing this file. It can't write the file, but then you'll never need to write to that file.

2. Add/merge that data into foobar's database.

3. DELETE the Play Counts file off the iPod. Or rename it to .bak or something. This is important, you want to clear that file so you don't get dupe counts.

4. When you build the new iTunesDB file, make sure to include the Play Counts info as well as the timestamps and such in the proper fields that are there for them. This is so smart playlists (if and when) will work correctly on 2.0 and up iPod's.

And that's pretty much that.

Edit: Part 2 is trickier than it seems. The Play Counts file is basically linked to the existing iTunesDB in such a way that the first song entry in Play Counts corresponds to the first song entry in the iTunesDB, and so on. So you'll need to have some way to work out which song in the foobar database corresponds to each song entry that already exists in the current iTunesDB in order to add the new playcount to the right place, update the last played time, etc. If you can sync though, you probably have a good idea of how to figure this out already.

If possible, I'd write something allow people to create their own text file templates which you then run through and fill in with the proper information. I know Foobar is all about customization, so this is probably the best option.

Like... err.. I don't know the details about foobar's supported scripting methods, but something like this, maybe (total psuedocode, I'm making it up as I go along):

template.txt
:foreach (%artist%) in all
:begin
<a href=%artist%.txt>%artist%</a>
:create %artist%.txt from artist_template.txt
:end

artist_template.txt
:foreach (%album%) in %artist%
:begin
<a href=%album%.txt>%album%</a>
:create %album%.txt from album_template.txt
:end

And so forth... Some kind of meta language where you can define loops and such, kinda similar to PHP's methods. There's probably something already in foobar you can do this with, I simply haven't delved in enough to figure it out yet.

Just keep in mind that there's a 4K limit on *any* note file. So you'll have to put in forward/back type links at the beginning/end of every file that goes over that limit and split accordingly. It gets tricky.

Lua scripting is on the long term list of features to implement in foo_pod, so when I add scripting and when I do something with Notes, I'll make sure that the Notes creation is controllable from Lua. In fact, other than providing the Foobar->Lua glue, I probably will do all of the Note support in Lua scripts, since my past experience with similiar situations has shown that scripting is always easier to maintain than a compiled language.

When I got to the 4kB limit portion of the Notes documentation, it really took the wind out of my sails. Without the limitation, it would be easy to completely customize the iPod GUI and do whatever you wanted with it. With the 4kB, that pretty much rules out most really useful GUI replacement features. Who would want to browse a directory structure, and have to press Select to go to the next page? Once you add in the pseudo-HTML overhead, I doubt that you could get more than 30-40 directories in a single Notes file.

wll, i've looked for such a nuul_diskwriter plugin, but couldn't find anything.. just to drag the files in a certain folder works, but there could be a nicer way, i guess

If you just want a folder type structure, then you don't necessarily have to do it entirely in that fakish HTML method. That's what the ".link" and ".linx" file type is all about. It'll support an actual folder structure that way.

If you put actual folders inside the notes folder, they show up with the arrow on the right side, like a subfolder. Then you can have subdirectories of things.

If you have a file ending in .link, then it goes directly to the first link inside that file. Consider it to be like a symbolic link on a unix-like system.

If you have a file ending in .linx, then it *appears* to be a folder, with the right arrow and everything, and that folder contains the links in the linx file itself.

So if you want to do a folder hierarchy, you can use a combination of these. The limitation here is that you have a maximum of 1000 entries on any folder or linx file.

Look, try it yourself. It's easy to work out. Just create your files in the Notes folder on the iPod. You can create any entire interface you like and never create one actual .txt file, sort of thing. Just link files and folders or linx files. The only disadvantage of this method is that it's displayed in the big font (just like all the other iPod screens) and not in the smaller font that it uses for displaying text files.

Example:
The Notes folder contains the folders Adam and April.
Adam contains Bob.link and Bill.linx.
Bob.link just contains:
<title>Play the Bob Playlist</title>
<a href="ipod:music?playlist=Bob">foo</a>
Bill.linx contains:
<title>Songs by Bill</title>
<a href="ipod:music?song=Bill's First Song">Bill's First Song</a>
<a href="ipod:music?song=Bill's Second Song>Bill's Second Song</a>

April contains a bunch of .link files, each pointing to one song, similar to Bob.link above, except pointing to a song and not a playlist.

When you look at this on the iPod, you can easily see the differences. The First screen has two choices: Adam and April. Both are folders.

Enter April and you see all the Songs by April. Select any of them, and hear that song. The thing is that you can have up to 1000 link files in there in this manner, and thus have up to 1000 entries under that folder.

Enter Adam, and you see "Play the Bob Playlist" and "Songs By Bill". "Songs by Bill" looks like a folder, "Play the Bob Playlist" does not. Select "Songs by Bill" and get a list of songs by Bill. Unfortunately, this is limited to the 4k limit, as it's a single linx file. But this would be fine for, say, a single album. It'd be preferable, in fact, because it loads a bit quicker than a folder with a lot of files in it. It'll also cache for quicker access on the second try. The "Play the Bob Playlist" just starts up a playlist.

Note that all of these, when they start playing songs, go to the Now Playing screen. Hitting the menu button goes back into the notes where you just came from, while it continues to play. It's just like the Browse interface in that manner. But you do have some control. Don't want a particular link to go to the Now Playing Screen? Add <meta name="Now Playing" content="false"> to any link file and voila, it won't go there anymore.

You really can create a nice interface. You do have to work around the limitations somewhat, but the 4k limit is not as limited as you might think, because you can get around it.

Additional:
Want to replicate an existing folder structure to the Notes exactly? Do this:
-Create the exact same folder structure on the iPod, in the Notes folder.
-For every song (MP3, AAC, WAV, AIFF), create a .link file with the following in it:
<title>%songname%</title>
<a href="ipod:music?song=%songname%">%songname%</a>

Want to speed that up a bit? Drop back a folder from the actual songs and create a .linx file instead, where it'll fit into a 4k structure.

I may be in the minority, but I have no interest in browsing my iPod by directory. The tag-based structure that exists right now works great for me.

I'm also a little worried that development based on 2.0 firmware will freeze out us Gen 1 iPod owners.

I'm not sure why you think non 3G iPod owners would be shut out. A Notes based directory browser (if implemented...it will take me weeks to wade through Otto's last post... ) would be optional for everyone.

You should be complaining to Steve Jobs and encouraging him to do a better job supporting older iPods!

<frink> Oh for crying out glaven... </frink>

Here you go. Unzip this sucker into your notes folder on your iPod. It's a demo of exactly what I outlined last night.

Note that the playlists and songs and such won't work unless you modify the proper files to point to songs you actually have and such.

http://otto.homedns.org:8888/itunes/notesdemo.zip

I may just write a simple command line tool to do this sort of thing. I can see where it'd be handy.

This is going to be great. Having done playlist syncs, soundcheck, etc etc, almost all iTunes features are emulated. Now starts the really cool stuff - New, innovative, incredibly useful stuff that we can tune to our liking.

Needless to say, I'm looking forward to it

Here's a very early test version of a program to create notes type structures from directory structures.

It has some big time limitations though.. Hey, I only coded it up in a few hours, and only to try it out and see how it would work, sort of thing. But somebody might be interested, so here it is.

http://otto.homedns.org:8888/iTunes/dir2note.zip

Simple usage:
dir2note <path to a drive or directory to create the notes> <path to a directory of Mp3s>

So, like this:
dir2note i: g:\mp3s
Simple. It'll create an i:\Notes directory and then copy the directory structure from g:\mp3s into it, replacing MP3 files with *.link files as it goes. The upshot of this is that if "i:" is your iPod, you get a bunch of notes that will mimic the directory structure of the MP3's on your machine.

dir2note -clear i: g:\mp3s
Same as above, but it'll delete everything in i:\Notes first. Be very careful here...

dir2note -clear i: NONE
Clears i:\notes only.. doesn't do anything else.. Not entirely useful given that you could do deltree just as easily, but what the hey...

Notes:
-Don't put trailing \'s on directory names.
-If a dir has spaces in it, surround that path in quotes
-FULL PATHS ONLY. This is important.
-It only works for MP3's right now.
-It only reads ID3 tags. Sorry to all the APE tag users, but I use ID3 tags and anyway it's only a preliminary version. Once the idea is fleshed out, and it's put into foo_pod, then you'll be able to enjoy.

Anyway, this is only for testing purposes, I don't recommend using it at all in any way on any machine anywhere ever, and if you hose all your files, that's your problem. Backup anything you run it on before running it on them. It's a demo only. Capish?

With this program, I uncovered one major limitation, BTW. When it says 1000 notes, it means it. 1000 notes, maximum. So forget being able to have one link file for every song (which this program, in fact, does). I'll have to use .linx files instead, methinks. Anyway, I don't recommend trying to put your entire directory structure in there, sort of thing. It won't work, yet. But, you can put several directories in by a series of commands. Like:

dir2note i: "g:\mp3s\audioslave"
dir2note i: "g:\mp3s\Weird Al"
dir2note i: "g:\mp3s\Soundtracks"

and so forth.. As long as you don't use -clear, it'll leave what's there there.

Version 0.5.1 is now available.


This release is mostly focused on performance. I profiled the entire application and optimized the most critical sections. I haven't measured the whole foo_pod to 0.5, but it is obviously much faster - the two slowest portions, other than file transfer, of a typical send/sync are now 10x to 100x faster than in 0.5!. There is one other major area that needs to be optimized, so there are still some easy speed improvements to come.

I also added experimental filename escaping for non-Latin based languages, so let me know if Asian filenames (for example) now work with 0.5.1.


From the Readme:
Version 0.5.1 - April 19, 2004
* Optimized several critical sections, resulting in much better overall performance.

* Added filename escaping for Asian and other non-European symbol filenames. Even though foo_pod handles such filenames correctly, the iPod itself can not play them.

I'm having problems with 0.5.1. Foobar crashes when I try to send files to the ipod. Right away an error window comes up saying there's a visual c++ runtime error. Then after I click OK, foobar terminates. For the interim, where would I find 0.5?

Version 0.5 can be found here.

I am having the same problem. Foobar crashes when writing the iTunesDB database file.

Ok, I've pulled 0.5.1 (although it is still available here if you want to test it), and I'll take a look at the crash later tonight.

Version 0.5.2 is now available.

This version should fix the crash that somasatellite and dragonfin reported. Otherwise, it is identical to 0.5.1.

Just to report that version 0.52 crashes foobar when writing the db. No error messages are given, foobar just shuts down.

Feck!

To those experiencing crashes (it works for me...honest!), which OS are you running? Also, does it work for anyone?

Hi Aero. I just experienced a crash on my first try as well.
The files transfered normally, but foobar2000 closed with the following message when it was going to write the db file.
Using Windows XP Pro SP1a!

Edit: Deleted LONG crash log.

I'm also using xp pro sp1.

Weird. Ok, I've pulled 0.5.2 and replaced it with 0.5 again. I'll try fixing it again later tonight.

I have a question:

I was wondering how foo_pod distinguishes between files when synchronizing with the iPod. The reason I am asking is because I do not enable foobar2000's database, the only way to see differences would be in something like filename or tags.

It would be a little odd recognizing files during a sync from their tags because I have some dupes in my collection (from soundtracks etc). This leads me to believe that foo_pod must store the original filename (and path?) on the iPod? So if I was to move some files to a new destination and sync again, would foo_pod delete the files on the iPod, and then transfer the moved files to the iPod again?

I'm just trying to get this straight in my head.

I am using Win XP pro too.

I don't know exactly which one of the many methods we discussed he's using to do it, but the iTunesDB file doesn't contain any place to put the original path and filename. So I'm fairly certain that that isn't it.

It's probably a combination of filesize and tags in some manner.

foo_pod currently uses a number factors to determine if a local file (i.e. on your hard drive) matches a file on the iPod.

First, it compares the file sizes. This is very simple, but remarkably powerful in eliminating non-matching files. As an example, out of approximately 7000 files I use for testing, there are maybe two files that have the same file size. File size also passively detects metadata changes, since such changes would usually result in a change in file size.

Next, foo_pod compares the file's creation and modification dates. Again, it is extremely rare to find any files with precisely the same dates. But since it could theoretically happen, foo_pod also compares several metadata tags, such as artist and title.

So only if files meet all of the above criteria are they considered to be a match. I could calculate a hash of each file, but that would be unusably slow. I believe that the odds of a false match are so low that this quicker method is preferable.


Getting back to your question, the location on the hard drive has no effect on foo_pod's matching algorithm, and it doesn't require that any path information is stored on the iPod. Even two copies of the same song aren't really duplicates unless they were created/modified at the same time, have the same filesize, and similar metadata. If all of that is true, then they are probably identical copies. In any event, foo_pod will only copy one of them to the iPod, and any duplicates will just be pointers to the one copy. That is how you can have the same song in multiple playlists, for example.

Anyway, I had to put a lot of thought into how to implement a sync matching algorithm, and I'm very happy with how it turned out in foo_pod.