Sorry if this has been addressed before. When I 'Send Current Playlist To iPod' it doesn't work if the files in the playlist are non mp3 or aac. I can send/transcode them to the iPod perfectly, but when the files are already on the iPod(previously transcoded) and I try to send the playlist(filled with lossless files for example) to the iPod it won't create a playlist. I realize that I can use the 'Load iPod Songs To Foobar Playlist' feature and then create my playlist from there, but it's a bit more painful. Just wondering if I am doing something wrong or if there is another easier way.

Another thing that may be useful is the ability to include DSP's in the transcoding section similar to Diskwriter. There are certain cases were it would be nice to use the equalizer on the transcoded file. Additonally, I'm looking forward to being able to lower the thread priority of transcodes if/when you implement that idea.

In any case, I love foo_pod just the way it is and sincerely thank you for increasing the enjoyment of my music.

Sincerely,
Pete

This is a known bug. In fact, ezekiel2517 brought this up in a recent post.


I already do use the Advanced Limiter when transcoding, so adding additional DSPs will be relatively easy. There probably aren't too many DSPs that would be useful - the only ones I can think of other than Advanced Limiter are Equalizer and Crossfeed. I'd rather not do a fancy GUI that would allow arbritrary DSPs unless there was a real need to have anything beyond Eq and Crossfeed.


Thank you!

"Skip silence" would also make sense so that you don't encode 13 minutes of silence between teh end of a track and the start of a hidden track on some albums.

Thanks Aero! I actually remembering seeing that post, but somehow it didn't mentally register when I noticed the issue and decided to post. Sorry, for being repetitive.

As for the DSP's, the main thing that came to mind for me was the occasional situation where I might want to EQ a song, for example if something is very bass deficient. Additionaly, I would be interested in experimenting with the 'Noise Sharpening' DSP on certain albums as well.

Thank you again! (Am I thanking you too much?)

Cheers,
Pete

Hey, could you post the album formatting string you are using for POD_ALBUM? I tried to reproduce your problem, but couldn't.

I assume you are doing something like this:

When I use this string, it seems to do what you are looking for:

Note the two single quotes after %artist%.

Version 0.9.9g is now available.

This is the first version with OttoFill. I'd say it is about 95% of OttoFill - the slider is fixed at 100%, so you can't specify how much space to use for music in this version. But otherwise, it should be ready for some serious testing.

Also, I added the requested transcoder priority and compilation TAGZ settings (in the Transcoder and Advanced preference tags, respectively). I also split the pre-amp volume into separate values for songs with and without SoundCheck.


From the Readme:

Yum! Thanks.

ROCK

That fixes it, but is hardly a nice solution.

This problem only seems to occur whilst my memory card reader is attached (which adds four extra removable drives).

I believe that foo_pod is polling each drive letter every so often in order to see if it's an iPod. If they're inaccessible, then yeah, that is going to cause some sort of slowdown I suppose.

Forcing the drive letter is probably the only solution. Unless there's some way to tell that a drive is an iPod without trying to access that drive.

You know I hadn't even thought of doing that, what a brilliant idea. Global metadata is brilliant.

All I've been doing is manualy setting a POD_ALBUM string on the files that required it. Then I attempt to send these files to the iPod. At no point do I use any TAGZ strings, it simply alternate metadata in the file. Sorry if I mislead you.

But why is it doing it on the right click. Unless you mean it's polling every second. Why can't it poll when you select mount iPod? Or when you try to send files to an iPod?

You rock, Aero!

The compilations TAGZ worked like a charm. This may be a silly question; however, the only way I could add the compilation tag to the files already on my ipod was to remove everything and resync the songs. Does this sound right, or is there an easier way to just update the ipod database?

Now Apple needs to add a "Singles" menu to the ipod

Not every so often, every time the context menu is shown/built (with foo_pod's menu items enabled).

Not really, it could just show the items that are hidden when an iPod is not connected and give an error message if they are tried to be used without an ipod connected. I wonder what would happen if I run those commands from the command line or smth without iPod connected.

Anyway I just removed foo_pod's items from the contextmenu. Problem solved, since I don't use them.

There isn't, unfortunately. That is a big shortcoming in foo_pod - the inability to modify the iTunesDB database without resending files. Ideally, you should be able to do certain things, like applying alt. metadata in place. I'll have to add that in a future version.

The problem isn't that foo_pod is polling. It is due to how I detect playlists that contain iPod songs, and those that are just regular Foobar playlists.

The reason I have to do this is so that you can right click on a song on the iPod, and get a contextually correct menu (Delete file from iPod, Save iPod File to hard drive) as opposed to right clicking on a Foobar file (Send file to iPod, etc.). I really don't know what the problem is - it seems to only happen for certain people. It definitely doesn't happen for me, on any of my home computers (including one that has a similar 4 drive letter flash card reader) nor on my work computer, so I don't really know how to fix the problem.

Forcing the iPod drive letter is probably the best solution, but if you don't use the foo_pod context menus, removing them works as well.

No worries! I just wanted to make sure I wasn't missing an option somewhere. Keep up the good work!

Now, onto album art

I'm just an iPod Photo and having some free time away from doing it!

Whenever I use foo_pod to send an MP3 in an MP4 container (made using foobar) my ipod can't play it. I assume it's because the file is not taken out of the container before it's sent to the ipod. Is this happening to everyone else or just me?

That sounds correct - neither foo_pod nor Foobar would do anything with your file, since it would appear as an MP3 format, and the iPod apparently doesn't handle MP3s in MP4 containers. foo_pod expects that any MP3 or AAC format files will be directly playable on the iPod without conversion.

I guess the only way for this to work (without stripping the MP4 container) is force foo_pod to transcode your MP3 files, by setting the "Transcode MP3 file above XXX kbps" to some really low value, like 1. This isn't ideal, but since I don't think Foobar allows components to know what container a song is in, it is probably the only way to make this work with foo_pod.

Hi Aero,

When transcoding having the option to use Replaygain(like DiskWriter) would be really useful, I'd be happy to go into more detail as to why if needed. Additionally, thank you for adding the thread priority option, would it be too much to ask you to add the option of 'Idle' also?... maybe in place of 'Above Normal'.

Your consideration and hardwork are really appreciated by this music lover.

Cheers,
Pete

Here is a little more background and some question I have about ReplayGain/AACGain/MP3Gain and their use with my iPod. http://www.hydrogenaudio.org/forums/index....t=0#entry287749

This is what started me thinking about the differences: http://www.dapreview.net/content.php?article.133

Thank you,
Pete

foo_pod already sends the ReplayGain information to the iPod using the "Soundcheck" field. So if you use foo_pod to transcode the lossless to a lossy format, the RG info should get put on the iPod as well (I'm pretty sure). Then all you need to do is to enable SoundCheck on the iPod and voila, it's done. No need to apply it during the transcoding itself since the iPod natively supports volume adjustment like this.

Hi Otto,

Yes I also understand things to be as you explain. The issue for me is that if I then scan those resulting files(that are on my iPod) making no changes with AACGain/MP3gain they frequently show as clipped. I'm concerned that the clipping is still there when using SoundCheck. Additionally, if you look at the second link from my previous post, there appears to be an issue of applying the iPod's EQ and it causing additional clipping/distortion when the source file's levels are already very high.

I hope my concern/explanation is understandable.

Cheers,
Pete

I am already applying the Advanced Limiter DSP during transcoding, so I wouldn't expect that the songs would be clipping as sent to the iPod - although if you apply heavy equalization on the iPod, the audio could definitely could clip. Maybe you should scale down the volume using foo_pod's preamp adjustments if you plan on using high levels of EQ on the iPod.

Okay, but the important question seems to be, are you actually hearing clipping from the iPod? Clipping is one of those easily noticable things, so determining whether the songs are actually clipping on playback or not is not particularly difficult to figure out. If you hear the static-like cracking sound, then they're clipping. Simple.

If you are converting lossless files to lossy ones and then get clipping from the lossy ones where there was no clipping in the lossless ones, then most likely any clipping being detected by MP3Gain is a result of the MP3 algorithim itself. While this is indeed clipping, generally I have found that it's so minor that it's unhearable, for me. You're only talking a few samples clipped.

One more thing is that if your lossless files have been normalized after ripping but before encoding, then getting clipping when converting them to an MP3 is quite likely. Don't normalize.

Two questions:

Any word on integrating iPod playcounts with the modified SQL playcount component?

and

Some people were talking about putting foobar on their iPod with an autorun.ini. This seems like something that would have broad appeal and as far as I know could be integrated into the foo_pod component (a check box: "Create foobar autorun.ini on sync"). Possible?

Not that I'm aware of. The last I knew, the playcount component wouldn't work with foo_pod (or any other component) that modified the playcount directly. But I haven't kept up with development, so this might not be true any longer...


For the autorun.inf thing to work, you have to have Foobar on your iPod. So maybe a checkbox wouldn't be the best way to do it, but I could include a sample autorun.inf in the foo_pod distribution that people could manually copy to their iPod.

I lost my autorun.inf I did when my first iPod Shuffle died, but I can easily recreate it. I'll post it here when I have it ready.

Ok, here is how I did my Autorun.inf for my iPod Shuffle (although it will work for any iPod), so that - depending on your OS, Service Pack version, and autorun preferences, it will do one of the following:
* automatically start Foobar2000 when you connect the iPod
* prompt you with an option to start Foobar2000 when you connect the iPod
* run Foobar2000 when you double click on the iPod drive icon
* nothing

1. The first thing you need to do is create an autorun.inf in the root directory of your iPod (i.e. on the same level as iPod_Control). I uploaded my autorun.inf to http://www.loodi.com/autorun.inf.

There are a few things you can change in here. The first is the drive's name, which will appear in Windows Explorer. You can force to whatever you want by uncommenting the Label line, and changing the text. Also, you can specify an icon - I am using the generic Foobar icon, but if you can change it to your favorite icon. I uploaded an iPod Shuffle icon, and there are also several different iPod icons online (such as these 4G icons, these icons, or these icons).

2. Copy your entire Foobar2000 directory from your computer's hard drive to root directory on your iPod. After you do this, you should have autorun.inf, iPod_Control, and Foobar2000 all in the same directory level, and in the Foobar2000 directory, you should have Foobar2000.exe. You might want to remove some unnecessary components to save room, and also delete the playlist in the Playlists directory.

3. This step is optional, but saves a lot of space and is especially useful on the slow iPod Shuffle, since it improves loading speed. UPX is a program that compresses .exe and .dll files, but does it in such a way that they automatically decompress as you run them.

Download the latest version, or get it from my website. I also uploaded a small batch script that you can use to automatically compress all of the Foobar .exe and .dlls. Copy upx.exe and foobar_upx.bat to your iPod's Foobar2000 directory, then double click on foobar_upx.bat.

You will get a few warnings, like:
upx: fooassoc.exe: AlreadyPackedException: already packed by UPX
upx: components\foo_matroska.dll: CantPackException: empty resource sections are not supported
upx: components\foo_playcount.dll: CantPackException: Structured Exception Handling present (try --strip-loadconf)
but you can ignore these.



After all of this is completed, you'll have a mobile Foobar2000 installation (hopefully with foo_pod!) that you can connect to any Windows computer and load songs onto and copy songs from your iPod.

Thank you again Aero, your Autorun.inf and Foobar onboard iPod is the dog's bollocks!

Otto, thank you for your informed response. I guess what I'm getting at is that I want to better understand the difference between creating an AAC file with Diskwriter with the ReplayGain button engaged vs not using the replaygain and then as a second step using AACGain. I believe there is a difference but am not 100% sure what it is. So... what if any is the difference in the resultant lossy file.

Cheers,
Pete

Heh...I had to look that phrase up to make sure you weren't insulting me!


I looked at the Diskwriter source code, and what the ReplayGain checkbox does is scale the audio as it is being written. But it only works if the song already has ReplayGain metadata - it doesn't calculate it on the fly. So if your song has been processed by AACGain, it probably won't have ReplayGain information and nothing will happen.

I think that the only time you would want to use this is if you want the audio to be permenently scaled to prevent clipping. Since the iPod has SoundCheck, which does the same thing but can be turned on and off, there really isn't any reason to permanently scale the audio.

One thing to note is MP3/AACGain work differently than ReplayGain. MP3/AACGain permanently (but reversibly) alter the song, while ReplayGain just calculates the scaling factor and writes it as a metadata item. MP3/AACGain have the advantage in the they aren't dependant on a player that supports ReplayGain/SoundCheck.

I guess the major point is that you should use either MP3/AACGain or ReplayGain/SoundCheck. If you only use Foobar and an iPod to listen to music, ReplayGain/SoundCheck is probably the best solution.

Okay, conceptually, the diskwriter is basically transcoding the file. It converts the file to WAV, then compresses it using whatever format you want. The important bit here is that it always first goes to WAV (even if this WAV file is only stored in memory and never gets written to disk).

When you tell the diskwriter to use the ReplayGain information, it will scale the intermediate WAV file according to the ReplayGain adjustment needed. It's like WAVGain in this respect. The scaled WAV is then what gets passed to your compressor.

MP3/AACGain, on the other hand, work differently. They adjust a parameter in the lossy file itself which changes the volume, in 1.5 dB increments. They also can write metadata to the file that allow fobar to deal with it properly and so forth.

Both of them actually change the song data itself. Diskwriter does it before compression, MP3/AACGain does it after. Of these two, Diskwriter's method (WAVGain) is a lossy process. There is always some round off error involved in scaling a WAV file. This error is minor, but additive. MP3/AACGain is a lossless process. It's only adjusting the global gain values, and it's doing so in a fully reversible way. However it is limited to 1.5 dB adjustments, where the other one is not.


The ideal approach is to rip the CD bit for bit, and do absolutely nothing extra to the data. The data from the CD is as good as it will ever get, so you want to do as few lossy things to it as possible. Compressing to lossless is what you have done, so this is not harmful. Then you want to compress to lossy. This is where you say you get clipping, but again, I ask, are you really hearing clipping? Just because MP3/AACGain says that it clips doesn't mean that it's really audible.

When you rip a modern CD, especially a rock/alternative/pop one, the tracks are quite likely to be somewhat clipped already. Not a lot you can do about it. However, this is not clipping that a program will be able to see easily. All it can see is that several samples in a row are at digital full scale. The actual clipped peaks are gone. When you then do lossy compression on this track, the resulting MP3 or AAC might indeed be clipping. What clipping means, in this context, is that if you decode the MP3/AAC, that some samples will be above digital full scale and will thus be clipped. But this is an artifact of the encoding process itself. The waveform you get out of the lossy compressed file is not the same as the one you put in. Those clipped sections will be approximated, and yeah, you can end up with a peak higher than full scale. Does this mean it's clipped? Sure. Does this means it sounds different than the original? Not at all.

And then clipping can be minor too. If on decoding an MP3, one sample comes out at digital full scale + 1, well, that's technically clipping, but there's no way in hell anybody could ever hear it. But MP3Gain/AACGain, these will report the thing as clipping nonetheless.

If you listen to a song, and hear no problems, and then MP3Gain/AACGain tell you it's clipping, don't worry about it. What you hear is more important than what the program tells you. The real reason MP3/AACGain warn about clipping is because you can adjust the gain of a song upwards and cause clipping when there was no clipping before, and this is usually very, very bad sounding.

Okay, so this is kinda long, but the short of it is that the foo_pod clienc really doesn't need RG in it, because the RG->SoundCheck functionality takes care of it, and applying RG before the compression process is not the best way to do it anyway.

Aero, I'm an American living in Tokyo but I have a lot of English friends here so I've acquired a bit of their slang :-)

I had understood the difference between RG and AAC/MP3gain, but was unclear about Diskwriter's implementation of it. All my files except for MP3 have been RG a long time ago and all my MP3's have been MP3Gained. I guess with AAC I need to make a choice whether to just transcode with RG/Souncheck metadata(your implementation, foo_pod) or to transcode(Diskwriter) and then run AACGain on everything, then transfer to my iPod. My concern is applying the EQ and getting additional clipping. As mentioned by you before, it looks like I can just lower the global gain(pre-amp) setting. That will allow me to apply more aggressive EQ settings without clipping, is that correct? Currently, I only use the 'Piano' EQ setting because it is one of the most subtle and doesn't introduce any audible clipping. I just want to play with the other EQ settings but most assuredly will return to something more neutral such as 'Piano'. Thank you for your explanation and patience.







Thanks Otto, this really gets to the heart of it for me and makes things crystal clear.



As a purist I agree wholeheartedly with this supposition, but unfortunately it is frequently impractical.

Aero & Otto thank you both!

Cheers,
Pete

Getting Album Art onto iPod

This shouldn't be too hard... except of course that Foobar doesn't support reading binary tags (ID3v2 or MP4/AAC) so you can't simply extract the art from the music file.

However, what about copying art that comes from the same folder as the music. In particular aligning yourself with the configuration that foo_uie_albumart uses? I could live with copying the first image file you find (which is iPod Photo compatible...not sure what that is).

Hmm...maybe this is more difficult than I think? Does the iPod have a proprietary image thumbnail format?

+Reardon

Yep. Before Aero sadly lost his iPod Photo, he documented it somewhat, and I put some of that on the iPodLinux wiki. Some other people have modified that a bit, but there's not yet enough knowledge there to create the files solely from that document.

I even had a small .NET application that would write album art to the iPod Photo. But like Otto said, the ArtworkDB format hasn't been completely documented yet, and without the equipment, it is pretty hard for me to do anything useful.

Just a minor tip for those wanting to try this.. I tried it on my 30 gig iPod and had absolutely no luck getting it to actually autorun a program using XP. I did some research on Microsoft's site, and finally got it to work by adding "UseAutoplay=0" to the file. This appearantly disables the newer XP Autorun crud and forces it to use the old Autorun methods in previous incarnations of Windows. Whatever it does, it worked.

Just a heads up.

That's pretty odd. First of all, there seems to be almost no official documentation for "UseAutoplay=0" (the only Microsoft information I could find was in a MSDN Magazine article). And secondly, that article seems to indicate that UseAutoplay=0 is the default behavior. I wonder if somehow your machine is set to default to Autoplay=1?

Thanks for the info - I've updated the autorun.inf file with your fix.

I haven't been able to find a whole lot of info about it either, but that article was where I got it from. I don't know how the default would be different, but I did notice that XP behaves differently for removable USB/1394 hard disks vs removable media like CD's. The article says that it defaults to 0 when there's an autorun.inf with no value present, but I think that's a mistake in the article and that the default may be 1 in certain cases like removable USB/1394 hard disks. I know that it certainly defaults to 1 when there is no autorun.inf present, in fact. Sticking my CompactFlash card in triggers the new XP AutoRun crap, for example.

My iPod didn't trigger anything *until* I added the autorun.inf file to it, and then it started giving me the new XP pop up window to choose an action. So it definitely thought that it was supposed to use the AutoplayV2 functionality somehow.

would be nice if the plugin checked the available space before copying. also, when there's not enough space, there should be a message telling so. right now it just aborts the transfer without feedback.

That is easier said than done, due to transcoding. Say you have 1GB of space free on your iPod, and you've got 2GB of FLAC encoded files. They might transcode down less than 1GB, but you won't know until after they are already transcoded.


That is not correct - information regarding the problem is outputted to the Foobar console.

Hmm... If it's CBR it's could be estimated "close enough" to be accurate. Add up the song times, multiply by the bitrate, divide by 8. Ignore tagging since you're likely not tagging anyway (there's little point since the iPod doesn't care about tags).

With VBR it'd be more difficult. You could overestimate (say, assume 220 kbps) and then warn the user that there may not be enough space, and offer to continue anyway. Even an estimate would be better than simply running out of space on the thing while trying to copy.

Since the user can not only specify custom encoder settings, but also custom encoders, there is no way for foo_pod to know if an encoding will be CBR or VBR, let alone the expected bitrate.

Hi Aero.

I really appreciate your work but I have a (small?) feature request: would it be possible to show the list of files involved (to the console, to file, whatever) before synching? Ideally with the action (replace, delete, add) that is going to take place.

I have two PC (home and work) with the same library; whenever I make changes (adding, removing, re-tagging, etc.) to one of them, I flush the changes to the iPod and then I use the synch function to keep the two instances... well, in synch. However, sometimes I'm prompted for a number of files to delete that I don't expect and I couldn't figure out an easy to check what's going on.

Sorry for asking this, as I know you're not a great fun of the synch stuff. So, if you have time...

Thanks for reading (and I hope I made myself clear ).

Alessandro

Transcode two songs, then divide the sizes by the time of them in seconds. If the two are identical (given a minor fudge factor), then you can assume CBR and you'll have the bitrate. If they are different, you can assume VBR, although you have no idea what the average bitrate will be.

Yeah, that would be a really useful feature to add to sync. I don't think the Foobar console is really up to the task, though.

What would be cool is a vertically scrollable window, with 3 checkboxes (add, delete, replace) followed by the song name/filename.

So something like:

It would make things a lot more complicated for me, but ideally, you should be able to uncheck the boxes (at least delete and replace) to prevent foo_pod from modifying your files on the iPod.

It would be a pretty big programming change, but it would be nice...

Glad you agree. A txt file would be perfect for my needs.Yeah, I didn't dare asking so much! I understand this would imply a major redesign of foo_pod (BTW, a single checkbox would suffice, IMHO). Perhaps you might consider the release of a static report first: it seems far more easy to make but still quite useful (well, to me anyway).

Thanks for your time.

Alessandro

Is there some way to access / calculate the total file size of a playlist? I had assumed there was, but the posts I'm reading make it seem like file size is not implemented as meta data. Is there some roundabout way to calculate it or anything like that?

I use a single playlist to manage the songs I want on the ipod. Currently it's trial and error to determine if the entire list will fit on the ipod. If I could get a file size in the status bar it would be so helpful. Thanks.

Sure - just select all the songs in the playlist, right click, and select Properties - see Total Size. If you want to find the total size of an iPod playlist, load it into Foobar using the Load iPod Playlists as Tabs, select all the songs, and view the Properties.

If you want to go that far, make sure we can change settings in bulk. Checkboxes get pretty useless if you've got a list of 850 songs.

Great idea though!