foo_pod - Foobar2000 meets the iPod, iPod -> Foobar2000 0.8 Options

[Krpano]

Try selecting the iPod first (normally you shouldn't have to, but maybe it is a bug). Go to the Components menu in Foobar, then to foo_pod, and select "Select iPod To Use". Then select the drive letter of your Shuffle and click OK. See if that helps.

AWESOME !!!
Thx for this GREAT component, that has free me from the sh!t iTunes.
And thx for your fast replies.

[Aero]

Version 0.9.9a is now available.

The major fix compared to 0.9.9RC is that I was able fix Nexus6's problem with long filenames. And in the process of fixing it, I spend up the "Preparing Database" portion of sending files to the iPod.

I also fixed a problem where if you cancelled during "Preparing Database", it wouldn't copy files, but it would create the database entries, leading to skipped songs on the iPod. Also, I added additional information in "Delete All Songs and Playlists" to help prevent you from wiping the wrong iPod.

0.9.9a Update: After playing around with transcoding and my iPod Shuffle tonight, I noticed that transcoding was horribly slow. It turns out that the encoder (LAME in this case) was writing out the output file in lots of little chunks, and that it is much faster (5x or more) to write the transcoded file to the local hard drive, then move it in one transfer to the Shuffle. It is also faster for regular iPods, although the improvement is more like 10%. Also, I wasn't very happy with the default LAME "Good" setting, so I did some experimenting and found a set of command line arguments that result in ~128kbps, but still sound really good.


From the Readme:

CODE

Version 0.9.9a - February 13, 2005
*  Greatly increased the transcoding speed to iPod Shuffles.  Due to the low write transfer speeds of the Shuffle and the way files were being written, transcoding was taking an inordinate amount of time to complete.  Now, files are transcoded to a local temporary directory then moved to the iPod.  This increases transcoding speed by around 500% on the Shuffle, and around 10% on hard drive based iPods.
 
*  After experimenting with different ~128kbps LAME settings, changed the default "Good Quality" command line parameters to "-V7 --vbr-new -q0 --lowpass 17.5 --athaa-sensitivity 1".  The previous setting,  "-V5 --athaa-sensitivity 1" gave good quality, but the bitrate could soar well above 128kbps for some songs.  The new preset seems to hover consistantly around 128kbps, and at least with my ears and music selection, sounds better than the old preset.


 
Version 0.9.9 - February 12, 2005
*  Added full support for the iPod Shuffle players.  foo_pod treats the iPod Shuffle just like any other iPod, with a few iPod Shuffle specific features, including writing two text files, "Track_Order.txt" and "Shuffle_Order.txt" to the root directory of the Shuffle.  These allow the iPod Shuffle user to determine in which order songs will be played, in either normal or shuffle modes.  Other expected features, such as Play Counts and ReplayGain/SoundCheck are implemented and work just like regular iPods.

*  Added a "Fix Skipped Songs" feature to the foo_pod Component menu.  This can be used by iPod Photo users to fix the issue where certain songs with long filenames are consistantly skipped.  It isn't necessary to do this on other iPods.

*  Fixed a bug in the Playlist Editor where smart playlists with the "In The Last" action selected wouldn't work unless you manually set a time period (such as Days).

*  Fixed a database issue which caused "Date Added" smart playlists to not work as expected.

*  Changed the "Good" quality LAME setting to the latest recommended ~128kbps parameters.

*  Added the iPod Chooser dialog, which opens a small windows and lets the user switch between two or more iPods.

*  Optimized the transcoder to deal with the situation where the transcoder .exe is not found.  Also fixed some transcoder related memory leaks.
 
*  Significantly improved the speed of the "Preparing Database" portion of sending files to the iPod.  

*  Fixed a major bug introduced in version 0.9.8 when sending one or more files with long filenames (>31 characters).  If multiple files with the same first 31 characters where copied at the same time, there was a possibility the only one song would be copied, but it would show up in multiple places in the database.  If this has happened to you, you will need to delete any affected files and resend them.

This post has been edited by Aero: Feb 13 2005, 10:39

[Angaros]

So I just installed foo_pod and I'm absolutely delighted to be able to use fb2k instead of iTunes with my iPod. I've hit a snag though. After installing foo_pod I used the "Load iPod Songs To Foobar2000 Playlist" command but when playing songs in the list, the tags disappear. Foobar cleans them out. If I just right-click on them without playing I can view the tags through Properties, but if I double-click to play them, the tags get wiped. Works fine if I press Play button. Have I done something wrong here?

[.zolder]

Hi Aero, thank you for the new release

I have a feature request. I have far more mp3's on my pc than there can fit on my ipod, so i came up with a nifty tag-system. I have all my mp3's tagged with an IPOD tag. In there i write whether i want the files on my iPod.. YES or NO. I made a column string for it to show up in my playlist like this:



I now make a new playlist ONLY containing files that have the tag IPOD=YES and then sync my iPod with that playlist, but it would be so much nicer if this step would not have to be neccecary and foo_pod could just pick out all the files with the tag IPOD=YES out of my main playlist containing ALL my musicfiles with either the tag IPOD=YES or IPOD=NO when syncing with (or sending to) my iPod.

I really hope you will implement this!

This post has been edited by .zolder: Feb 13 2005, 16:20

[Nexus6]

Version 0.9.9a is now available.

The major fix compared to 0.9.9RC is that I was able fix Nexus6's problem with long filenames.  And in the process of fixing it, I spend up the "Preparing Database" portion of sending files to the iPod. 

Oh dear lord thank you! iTunes is now uninstalled. Keep up the great work!

[Aero]

So I just installed foo_pod and I'm absolutely delighted to be able to use fb2k instead of iTunes with my iPod. I've hit a snag though. After installing foo_pod I used the "Load iPod Songs To Foobar2000 Playlist" command but when playing songs in the list, the tags disappear. Foobar cleans them out. If I just right-click on them without playing I can view the tags through Properties, but if I double-click to play them, the tags get wiped. Works fine if I press Play button. Have I done something wrong here?

That is annoying, but not really a foo_pod bug. The disappearing metadata is caused by Foobar reading in the real metadata from the file, rather than the metadata that foo_pod provides from the database on the iPod.

You can see this by selecting Properties on a song in the iPod playlist, then clicking the "Reload info from file". Sometimes you'll just see the metadata get rearranged, but if there is additional metadata in the iPod database that isn't in the file, it the foo_pod generated data will disappear.

I don't know of any workaround for this problem, unfortunately.

[Aero]

Hi Aero, thank you for the new release

I have a feature request. I have far more mp3's on my pc than there can fit on my ipod, so i came up with a nifty tag-system. I have all my mp3's tagged with an IPOD tag. In there i write whether i want the files on my iPod.. YES or NO. I made a column string for it to show up in my playlist like this:

(snip)

I now make a new playlist ONLY containing files that have the tag IPOD=YES and then sync my iPod with that playlist, but it would be so much nicer if this step would not have to be neccecary and foo_pod could just pick out all the files with the tag IPOD=YES out of my main playlist containing ALL my musicfiles with either the tag IPOD=YES or IPOD=NO when syncing with (or sending to) my iPod.

Yeah, I can add this feature. I guess the only question I have is if "IPOD" is the best name for the flag. I was thinking something generic, along the lines of "SEND_TO_PORTABLE_PLAYER", but much more concisely worded.

This post has been edited by Aero: Feb 13 2005, 22:51

[Lyx]

ON_PORTABLE=1/0

[.zolder]

Great!!! I think Lyx has a good call

This post has been edited by .zolder: Feb 13 2005, 23:15

[Aero]

Version 0.9.9b is now available.

Another quick release, but I found a bug introduced in 0.9.9a that could cause files that fail during transcoding to still be written to the database.

Also, I added .zolder's suggestion to check for either the "IPOD" or "COPY_TO_PORTABLE" metadata items, and if they are set to "FALSE", "NO", or "0" (zero), do not send or sync the file to the iPod.

I saw Lyx's suggestion for ON_PORTABLE, but that indicates (to me, at least) more of a state situation than a directive not to send the file to the iPod. ON_PORTABLE could be interpreted to mean that a file is already on the iPod. So I setted on COPY_TO_PORTABLE, although if that is too wordy, you can simply use IPOD.


From the Readme:

CODE

Version 0.9.9b - February 13, 2005
*  Fixed an issue introduced in 0.9.9a where if transcoding failed (due to insufficient disk space, for example), the file would still show up in the database.

*  Added a feature to automatically skip sending/syncing files with either "IPOD" or "COPY_TO_PORTABLE" metadata set to "NO", "FALSE", or "0" (zero).  IPOD, COPY_TO_PORTABLE, NO, and FALSE are all case insensitive.

This post has been edited by Aero: Feb 13 2005, 23:27

[topdownjimmy]

Also, I added .zolder's suggestion to check for either the "IPOD" or "COPY_TO_PORTABLE" metadata items, and if they are set to "FALSE", "NO", or "0" (zero), do not send or sync the file to the iPod.

That's great...the use of this tag can also serve the purpose of displaying a track's iPod status in the trackinfo panel. Thanks Aero.

[.zolder]

Wow that's fast! Thank you so much! I'm gonna play with it and consider myself to be the happiest man alive for a while

[Lyx]

Thanks alot. But could you please change the "standard" to only check for "0" (zero)?

Checking 12 conditions with TAGZ in formatting-strings is messy.

Also, please consider that enforcing a clear standard like COPY_TO_PORTABLE may offer a higher benefit than the disadvantage of having to retag one's files one single time with the masstagger (which is just a matter of a few seconds).

- Lyx

This post has been edited by Lyx: Feb 13 2005, 23:51

[Aero]

Thanks alot. But could you please change the "standard" to only check for "0" (zero)?

Checking 12 conditions with TAGZ in formatting-strings is messy.

Also, please consider that enforcing a clear standard like COPY_TO_PORTABLE may offer a higher benefit than the disadvantage of having to retag one's files one single time with the masstagger (which is just a matter of a few seconds).

I would assume that the IPOD/COPY_TO_PORTABLE metadata would be created solely for the use of each individual user, so you can decide and enforce whichever standard you wish. foo_pod is simply able to handle several different variations.

This post has been edited by Aero: Feb 14 2005, 00:03

[Lyx]

*sigh* not another "play_date"-desaster...

- Lyx

[Aero]

*sigh* not another "play_date"-desaster...

Um...whatever.

This is essentially a boolean value, unlike something that is widely open to interpretation like a timestame. Having foo_pod able to accept "FALSE", "NO", or "0" does not impose any sort of standard on anyone, nor do I think foo_pod should since foo_pod is on the receiving side of the metadata.

If you choose to use Masstagger and set your COPY_TO_PORTABLE to "0", then that is your standard. If someone writes foo_copy_to_portable_setter.dll and it uses "NO", then you either switch your metadata and TAGZ strings to use "NO" or you don't use that component. Either way, foo_pod is able to handle the variation.

If it really bugs you that much, get a binary editor, open up foo_pod.dll, search for "COPY_TO_PORTABLE", and set "NO\0" to "0\0\0" and "FALSE\0" to "0\0\0\0\0\0"...



"In general, an implementation must be conservative in its sending behavior, and liberal in its receiving behavior." - Jon Postel

[Lyx]

Well, i'm sure you're aware that not every fb2k-user is skilled in the magicks of writing formatting-strings with TAGZ, right? But thats no problem because there are people like me who take out hundreds of hours out of their free time to write formatting-strings not just for personal use, but to make fb2k more usable for everyone.

However, the goodwill and flexibility of those people is limited - especially in cases like play_date where the only way to write a public formatting-style usable for everyone and doing advanced stuff with play_date is only possible by writing a truckload of code to GUESS what date-format the user may have set - just because the author of that plugin was ignorant to not just not use a standardized ISO-date and instead make it configurable - he even made the default the european-dateformat, just to make absolutely sure that the majority of users WILL change it to something unknown to the formatting-string author. And so he has to drop support for that plugin, because the author was too short-sighted and egocentric to get the big-picture.

For the same reasons, it's not viable to waste 2 IFs, 2 ORs, 12 STRCMPs and 12 tag-lookups, just to plain simply check if an integer is set.

But okay, its your plugin and your decision.

*removes half-implemented foo_pod support from his to-be-released Navigator FCS*

- Lyx

This post has been edited by Lyx: Feb 14 2005, 00:40

[Aero]

But okay, its your plugin and your decision.

I can understand where you are coming from, but having foo_pod able accept multiple formats is not a problem. There was no standard before I added this feature; there still is no standard. If you distribute your TAGZ strings or whatever, maybe you can create a groundswell of support and you will own the COPY_TO_PORTABLE metadata standard. Either way, foo_pod is ready.

*removes half-implemented foo_pod support from his to-be-released Navigator FCS*

Heh!

Based on your "take my toys and go home" attitude over this extremely minor issue, I'm overjoyed that foo_pod won't be associated with "Navigator FCS"...

[Otto42]

Gotta agree with Aero on this one. If you're making a program that is accepting unknown data that you know is a boolean, then you had best check for everything you know about. T/F, TRUE/FALSE, Y/N, YES/NO, 1/0, E/D, ENABLED/DISABLE(D), etc.

Frankly, checking for multiple items isn't all that damned difficult. Yes, it might be a PITA using "tagz", but if that's the case then why not extend tagz by creating a function called "check_bool()" or something that will convert all of the above to a simple 1/0, and thus allow everybody to simply use that? This sort of thing is why man invented subroutines.

And if it's a sheer matter of processing time, then perhaps your time would be better spent in improving the speed of the scripting language itself. This sort of input data processing is built into a lot of scripting languages, so extending the language in obvious directions would be a good thing, I'd think.

This post has been edited by Otto42: Feb 14 2005, 16:52

[foosion]

Gotta agree with Aero on this one. If you're making a program that is accepting unknown data that you know is a boolean, then you had best check for everything you know about. T/F, TRUE/FALSE, Y/N, YES/NO, 1/0, E/D, ENABLED/DISABLE(D), etc.

Would "etc." include translations of these words into several dozen non-english languages and abbreviations thereof? For programming languages, offering several ways to do the same thing is often considered an undesirable feature. Not only are you suggesting to allow a plethora of keywords, but checking multiple tags includes the possibility that these contain incompatible values. Btw. it takes longer for a human to recognize the meaning of a single-letter abbreviation than that of a whole word.

Frankly, checking for multiple items isn't all that damned difficult. Yes, it might be a PITA using "tagz", but if that's the case then why not extend tagz by creating a function called "check_bool()" or something that will convert all of the above to a simple 1/0, and thus allow everybody to simply use that? This sort of thing is why man invented subroutines.

It seems like you are trying to apply some general principle (good) without reflecting upon the situation at hand (bad). foobar2000's titleformatting language is limited which makes the test at hand cumbersome to implement in it. Sure, it can be changed, but: you can't do it, Lyx can't do it, and Peter won't do it unless asked to. If he agreed to add that, I doubt he would roll out 0.8.4 just for that, so users would have to wait several month until 0.9 is released.
Now perhaps you or Areo have already inquired Peter about that, I don't know. All I've seen is that Aero laughed at Lyx's frustration. I would like to believe it was a friendly "relax, man" kind of laughter, but the next sentence suggests otherwise.

And if it's a sheer matter of processing time, then perhaps your time would be better spent in improving the speed of the scripting language itself. This sort of input data processing is built into a lot of scripting languages, so extending the language in obvious directions would be a good thing, I'd think.

You seem to be ignorant of the fact that the titleformat interpreter is implemented in the core, and the core is closed source. Suggesting Lyx that he should improve this interpreter is a bit odd.

What would in your opinion be wrong about simply checking for the existence of a tag called COPY_TO_PORTABLE or DONT_COPY_TO_PORTABLE (depending upon which you decide to be the default)? It would be easy to check manually and programmatically (even in tagz), and would be easy to change by the user as well.

[Otto42]

You seem to be ignorant of the fact that the titleformat interpreter is implemented in the core, and the core is closed source. Suggesting Lyx that he should improve this interpreter is a bit odd.

I know absolutely zero about how foobar works. I've looked at the code in the SDK, but couldn't make heads or tails of it (admittedly I did not try very hard). I was basically just expounding on general principles.

To be honest, I have no idea WTF "tagz" is. I do not use foobar nor foo_pod, as neither one is capable enough to fit my day to day needs at this point. I like the concept and the idea, and so I'd like to see it improved to where it's useful enough for me to use it. That's why I contributed code in the hope that somebody would create an iPod plugin in the first place. In other words, I try to offer help when and where I can, sort of thing, in the hope that foobar will eventually progress to where I can use it for the sort of things I do. At the moment I'm forced to use iTunes, and I'm not happy about that either. But it's the only program capable of playing my songs in the way I like them to be played, and keeping the metadata in the way that I like it to be kept. Too bad it's a resource hog with a crappy interface.

This post has been edited by Otto42: Feb 14 2005, 21:33

[foosion]

You mean to basically assume true (or false) if the tag with that name exists?

Yes.

That seems like a pretty poor way to do things given that a tag always takes the format of X=Y by default, no?

I agree that ignoring the tag value may seem like wasting the capabilites of the tagging system, but I'm wondering if using the mere presence of the tag isn't enough here. People have already used a VA tag as a flag on various artists albums, so it is not an entirely uncommon solution.

I mean, there is no standard, and implementing it one way or another in some component does not a standard create, as I see it. So if it's gonna be configurable, make it really configurable.

An unneeded option is a bad one. Not only does it take up space in the preferences and adds to the confusion of new users, if you change it, you have to change it in every place it is used. This is something I had to learn myself: to keep the amount of options to a minimum, and to resist the temptation to abuse titleformat scripts in options. In the end, this has made my components easier to use for myself (hopefully for others as well), though that process is not yet finished.

I saw that you edited your post while I was replying, but I felt the need to clear up those points.

[Aero]

Would "etc." include translations of these words into several dozen non-english languages and abbreviations thereof?

What would in your opinion be wrong about simply checking for the existence of a tag called COPY_TO_PORTABLE or DONT_COPY_TO_PORTABLE (depending upon which you decide to be the default)?

Using the logic in your first quote, we would have to localize the tag names as well...

All I've seen is that Aero laughed at Lyx's frustration. I would like to believe it was a friendly "relax, man" kind of laughter, but the next sentence suggests otherwise.

Actually, it was more of a "we were having a civilized, technical discussion (even if you were being unnecessarily dramatic), then you threw in that last little bit and completely destroyed your credibility" kind of laughter. Take it however you wish...

Anyway, this matter is closed for now. foo_pod implements the "IPOD"/"COPY_TO_PORTABLE" metadata as described in the Readme file. If there is ever a good reason to consider revising the support in the future, I will update foo_pod accordingly.

[foosion]

Using the logic in your first quote, we would have to localize the tag names as well...

My logic? I did not suggest to allow translated tag values, I even gave a reason why i would consider it undesirable in the next sentence (which you did not quote). Another good reason against localizing tag names is that neither APEv2 nor Vorbis Comments allow non-ASCII characters in tag names.

[Lyx]

Users will always be the ones who have to pay for ambigious and unclear standards, no matter in which topic. You call it userfriendly, but it's the opposite in the long run because it results in incompatibility.

This post has been edited by Lyx: Feb 16 2005, 01:43