*** October 3, 2006: The latest version is 0.9.9o - read about it in this post***

If you are new to foo_pod, skip to the end of the forum for the latest development and discussion, as foo_pod has advanced quite a bit from this initial post...

http://www.tinkafoo.com/log/foo_pod.html is an excellent source of information about foo_pod, and might save you 8+ hours reading this forum trying to find the answer to a commonly asked foo_pod question.

Here is my initial release of a Foobar 0.8 component to interface with an Apple iPod. The current version (0.1) only supports read access to an iPod - namely, reading the iPod database file and building a Foobar playlist containing all of the songs contained on the iPod.

Is this useful? Maybe...

By building a playlist of all of the songs, you could take your iPod to a friend's computer and play the music and copy songs off of the iPod (by dragging the song from the playlist to a directory or the Desktop), without any additional software. This component might also be useful for people with home theater PCs - leave the iPod dock on the HTPC, sync up on your main computer, and playback directly from the iPod on the HTPC.

To use foo_pod, make sure your iPod is connected to your computer and is visible as a drive in My Computer (very important), and select Components/foo_pod/Load iPod to foo_pod Playlist. There are a few preference settings, but unless the automatic detection doesn't work, you probably won't need to change anything.

Anyway, let me know how this works out on different computers/iPods, and what features people would like to see. I would like to get Foobar->iPod writing working, but I'm pretty happy with EphPod, so we'll see what happens with that. Eventually, I would like to do something like Anapod. I actually have written a component that handles HTTP access/streaming and is more functional than Anapod, but I never updated it from Foobar 0.6...

Special thanks go to Otto42 and his excellent iPod classes. foo_pod relies heavily on Otto42's code, with some minor modifications (Otto42 - remind me to send some diffs). Also, on another thread, Scream mentioned that there is source code available for the Winamp5 plugin. I haven't tried that plugin yet, but I wouldn't mind taking a look at the source, especially for supporting write access (the posted link appears to be dead).

Aero, I tried to download the modified iPodDB classes you sent me via email, but the link didn't work. If I could get ahold of the modified classes you've made, I could work in some other changes. In particular, I've modified the iPodDB classes to include support for the BPM field, and better support for the mhod types. I've also got a small start going on write support.

And frankly, I'd love to get rid of the hard coded limits on song numbers and such, and if you'd done that, it'd be awesome.

Any chance you could figure out how the Ipod's soundcheck feature works and allow foobar to write replaygain info in sound check form?

Yeah, probably. I'm 95% sure that it's one of the fields in the iTunesDB. Probably one of the "unknowns" I have in there already. Then again, maybe not. In any case, I'll check it out after I get the writing capability working. With Aero's changes, it's going to be slightly easier for me to get the write stuff into the classes. I've already got his changes and mine integrated, now I'm just finishing off the write code that I started a couple weeks ago and never got back around to. I should have it working, at least partially, in a day or two.

The thing about adding write capability is that there's a *ton* of fields in the iPod that I just don't know what they mean. When I wrote all the read stuff, I simply left out a lot of those. But now trying to write them out, I don't know if I can set them to nulls or not. So I'm having to go back into the parsing code and add a lot of unknown entries just so that I can write them back out to the resulting file. It's a bit annoying, but it'll make for a lot of capability, even if you don't know what 50% of that capability actually does.

Anyway, once I have all the fields actually being read, then it should be a simple matter of looking at what iTunes says is the "gain" on the track and finding which field in the iTunesDB corresponds to that. Then one could just write the correct entry into the newly found "gain" field and voila, sound check works. Neat, huh?

Excellent excellent excellent! I am extremely happy to see this project take off.

One feature that I've been looking for in other iPod interfaces is the simple ability to sync my iPod with a directory - I wanted all of this database stuff to happen behind the scenes, so I could just synchronize quickly with my Music folder (which is updated regularly with new CDs I purchase) and be on my way.

Perhaps this brings me a step closer to such a program. I can't wait to see what you come up with! I'm tired of iTunes slowness.

Reverse-Engineer the iTunes smartplaylist feature. (if you do,you might want to add it to foobar as well)

Personally, as i have said in many other threads, Foobar needs a full database like other database mp3 software (iTunes, Media Center 9/10) before a iPod plugin can be made that rivals iTunes. But if want an Ephpod killer, you're nearly there. I would rather see foo_pod go all the way and kill the need of iTunes on my PC. Thanks, and good luck with more of this plugin development. If you need someone to help test it out. I have a 20gb 3rd gen that i can work with.

Got writing fully implemented. It's still untested though, so it's probably broken somewhere. Still needs some work in other words. At the moment, I'm trying to get it such that reading and then immediately writing the iTunesDB (going through my code of course) will produce a 100% identical file. Then I know it's working properly and everything is being parsed and recreated correctly.

And man, I looked and looked for where the gain for the soundcheck might be being stored, and I am at a total loss. It's just confusing as hell in there. Anybody know how Mac's tend to store floating point values? That might help. I know that the songs in iTunes show a value of "-4.3 dB" and similar for the "volume" when I do a Get Info, but I don't understand audio enough to understand what, exactly, that means. Somehow, iTunes has to tell the iPod how much to raise the volume for Sound Check mode. But I don't know what kind of data it would pass across to let it do that.

Furthermore, it may not be in the iTunesDB. I know for an absolute fact that when iTunes does its volume scan on an M4A/AAC file, it adds a tag to the file that seems to have something to do with the volume. Perhaps the sound check data is in the files themselves, and the iPod then uses that accordingly. If so, then it's a matter of changing the file tags appropriately. I don't know if it adds anything like that to MP3's though, I haven't checked.

Edit: Ahh.. okay, if it is in the file comment tag then it's something that will have to be added to whatever foobar plugin handles the tagging of the files themselves. Of course, that means figuring out the format of itunes weird tag.

I assume this is the soundcheck data. A way is needed to create these fields via replaygain values.

I think the reason it writes it in the comments field is because when you add new fields to ID3v2 tags it has to rewrite the file and i guess the programmers of itunes found a way around it by just writing it in the comments field.

Now, AAC files on the other hand have a fields called "ITUNNORM" followed by soundcheck stuff.

Okay.. That's really weird. I checked loads of my files and couldn't find that in there. So I removed one of them from the library then added it back to the library. Voila, it added that field. But the problem with that is that the file already had a COMM field in the ID3v2. Now it has 2 of them, the previous one and a new one immediately following that one. Freakin' odd, that is.

I don't think the Ipod knows what a file tag is. From what i gather its all handled by iTunes. WHich makes sense since the Ipod needs to load as quickly as possible while using as little of its meager processor and battery as possible. I'd guess that those tags are just for compatability with other iTunes clients and as a backup incase the user formats or otherwise loses itunes's db.

About the numbers themselves, perhaps the gain values are stored as integers? That would make sense since I think the ipod's processor is int only.

I don't think the Ipod knows what a file tag is. From what i gather its all handled by iTunes. WHich makes sense since the Ipod needs to load as quickly as possible while using as little of its meager processor and battery as possible. I'd guess that those tags are just for compatability with other iTunes clients and as a backup incase the user formats or otherwise loses itunes's db.

About the numbers themselves, perhaps the gain values are stored as integers? That would make sense since I think the ipod's processor is int only.

Got me man. It's quite possible it's in the iTunesDB file. There's still a heck of a lot of unknown's in the MHIT records. Could easily be one of them.

In any case, I'm done with the writing portion of the classes. They work. I've gotten them to the point where I can feed an iTunes created iTunesDB file from my own iPod, parse it, regenerate it from the structures in memory, and write it back out to a file, and have absolutely no differences in the resulting file from the original. Which tells me that it's correctly generating the file, more or less. Obviously, if you change the structures incorrectly, you get incorrect results, but that's not the classes fault.

I also included the test program. It's pretty self explanatory. Feed it an iTunesDB, get back an iTunesDB.new. If iTunes originally made the thing, then the resulting iTunesDB.new should be identical, minus your changes to the objects in memory.

Also added is a whole lot of new fields, including everything in the file that didn't look like it was just null padding. Have fun.

Im pretty sure Mike is right here. Everything on the ipod is handled via the Database. And im sure it writes to the file because sometimes things crash and burn. So its there. It doesn't really matter.

So we found the SoundCheck thing on the actual files. Thats a start, gives Otto here something to tinker with. =P

Also the iPod is int only (thats why we'll never see APE support on it, or any of those fancy codecs), but that doesn't mean the SoundCheck has to be. iTunes does all the scanning and voluming changing before hand, and simply writes a volume delta to the database.....which leads me to the next point....

There's 16 unknown fields in the MHIT right now (The MHIT is what describes a "song" to the iPod). And it could only be part of those fields. And I don't know the exact format of what I'm looking for. And I don't know what value it would be even if I knew the format it was in.

So, gimme some time.

Edit: The field in the MHIT designated "unk3" in my iPodDB classes seems to correspond to the first 4 bytes in that iTunNORM comment that is added to the song's tags.

Synched with the iPod. unk3 now contains "00 00 0B F7" after byte reversal. Get Info shows a -4.9dB Volume on this one.

None of the other stuff in that iTunNORM can seemingly be found anywhere in the file where it would make any sense. So if that iTunNORM is related to the Sound Check, it seems as if only the first four bytes are necessary. Maybe that's the amount that it pumps up the volume in some way? I could try setting unk3 really high for a song and seeing if the iPod plays it back super loud... Still, that only tells us what to change, not how much to change it.

That is definitely it. When I changed that particular unk3 field from 0x0BF7 to 0x7BF7, the song got a *lot* quieter when the sound check was on. I'm going to play around with it and see what I can find, but that's definitely where the trick is.

I'll probably rename unk3 to something else once it's worked out what the field represents. I can't think of why it would get quieter as the value gets larger. And I tried to avoid going above 0x8000 thinking it might be a signed value. I'll mess around with it some more.

Still, if anybody knows ReplayGain really well, it would help if you could drop in your input on how much volume equates to what sort of change.. We're going to need some way of calibrating this to determine how much to change it for what gain value needs to be applied. I don't grasp audio and gain well enough to really know what the hell I'm doing here.

The Sound Check field, or "unk3" as it's labeled in my code at the moment, is set by iTunes as part of the volume scan. The purpose of this field is to sorta normalize the volume across multiple songs somehow. You can't adjust this field yourself within iTunes. If you turn Sound Check on and off, you'll hear the effect that this field has turn on and off.

The Volume Adjustment field you *can* adjust from within iTunes. If you do a Get Info on any song, there's a slider where you can manually adjust the volume of a song, on a per song basis. Basically you can add 10%, 20%, that sort of thing. Anyway, this volume change is applied whether Sound Check is turned on or not. The purpose is to boost the volume above normal volume manually. This field is labeled "volume" in my code at the moment.

Two separate fields. One is activated by sound check and has some weird scale that I haven't worked out yet. The other is global and always on and has a scale from -100 to 100 or something like that.

I thought the iPod handled all metadata through its internal database, so which tags are on the files should not matter, unless you're going to erase your local copies and import everything back from the player at a later time.

I meant out of ID3v1 and APEv2 (the two formats I use), iPod only reads ID3v1

I don't think the iPod using any tags and relies on its database for this information. When I first got my iPod I noticed that I got different results with different applications (XPlay, ephPod, iTunes) so I think it is up to the PC (mac) side application to do whatever it wants as long as it builds a valid iPod database to put on the device.

I would think the foo_pod will fill in the database by asking foobar for particular meta_data and won't care where the data originated (id3v1,v2,etc.)

Correct me if I'm wrong, Aero.

My questions about foo_pod are how you plan to handle syncing the iPod once write is added to the code base.

Will it be realtime as you add/remove songs to the foo_pod playlist, on demand by a context menu or main menu choice, or something else. Is on the fly possible or does the database have to be entirely rebuilt for every change and then entirely copied to the iPod?

Anyway, if I can get songs on/off my iPod without all the other applications I'll be more then happy.

The iPod doesn't understand any tags whatsoever. Not ID3, not APE, nothing. All of the data the iPod knows is contained within the iTunesDB file.

iTunes and other programs build that iTunesDB file by using ID3 or what have you tags. So, if foobar understands APE tags, and if foobar is building the iTunesDB... QED. You can build the iTunesDB using any info you want from any source you want. That's what the iPodDB classes I wrote do. They let you read an iTunesDB into memory, modify it, write it back out. Or, in theory, you could build the class/object structure in memory from scratch and then write that out as a valid iTunesDB file. I'm working on a way to make that *much* simpler to do, as right now building a DB from scratch is a PITA.

Addition: iTunes doesn't modify the songs before copying them to the iPod. It may modify them when you add them to the iTunes library itself or when you change the tags using iTunes, but the process of synching the iPod just copies the files over in their current state. It's the iTunesDB that controls the rest.