Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: foo_pod - Foobar2000 meets the iPod (Read 1309827 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

foo_pod - Foobar2000 meets the iPod

Reply #1275 –
Quote
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.
[a href="index.php?act=findpost&pid=287767"][{POST_SNAPBACK}][/a]

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.

foo_pod - Foobar2000 meets the iPod

Reply #1276 –
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?

foo_pod - Foobar2000 meets the iPod

Reply #1277 –
Quote
Any word on integrating iPod playcounts with the modified SQL playcount component?

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...

Quote
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?
[a href="index.php?act=findpost&pid=287849"][{POST_SNAPBACK}][/a]

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.

foo_pod - Foobar2000 meets the iPod

Reply #1278 –
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.

foo_pod - Foobar2000 meets the iPod

Reply #1279 –
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

foo_pod - Foobar2000 meets the iPod

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

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

Quote
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.

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.

foo_pod - Foobar2000 meets the iPod

Reply #1281 –
Quote
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.
[a href="index.php?act=findpost&pid=288036"][{POST_SNAPBACK}][/a]

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.

foo_pod - Foobar2000 meets the iPod

Reply #1282 –
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.



Quote
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. [a href="index.php?act=findpost&pid=288087"][{POST_SNAPBACK}][/a]


Quote
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. [a href="index.php?act=findpost&pid=288087"][{POST_SNAPBACK}][/a]


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

Quote
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. [a href="index.php?act=findpost&pid=288087"][{POST_SNAPBACK}][/a]


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

Aero & Otto thank you both!

Cheers,
Pete

foo_pod - Foobar2000 meets the iPod

Reply #1283 –
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

foo_pod - Foobar2000 meets the iPod

Reply #1284 –
Quote
Does the iPod have a proprietary image thumbnail format?
[a href="index.php?act=findpost&pid=288334"][{POST_SNAPBACK}][/a]

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.

foo_pod - Foobar2000 meets the iPod

Reply #1285 –
Quote
Quote
Does the iPod have a proprietary image thumbnail format?
[a href="index.php?act=findpost&pid=288334"][{POST_SNAPBACK}][/a]

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.
[a href="index.php?act=findpost&pid=288353"][{POST_SNAPBACK}][/a]

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.

foo_pod - Foobar2000 meets the iPod

Reply #1286 –
Quote
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. 
[a href="index.php?act=findpost&pid=287930"][{POST_SNAPBACK}][/a]

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.

foo_pod - Foobar2000 meets the iPod

Reply #1287 –
Quote
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.
[{POST_SNAPBACK}][/a]

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 [a href="http://msdn.microsoft.com/msdnmag/issues/01/11/autoplay/default.aspx]MSDN Magazine article[/url]).  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.

foo_pod - Foobar2000 meets the iPod

Reply #1288 –
Quote
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?[a href="index.php?act=findpost&pid=288607"][{POST_SNAPBACK}][/a]

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.

foo_pod - Foobar2000 meets the iPod

Reply #1289 –
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.

foo_pod - Foobar2000 meets the iPod

Reply #1290 –
Quote
would be nice if the plugin checked the available space before copying. also,

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.

Quote
when there's not enough space, there should be a message telling so. right now it just aborts the transfer without feedback.

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

foo_pod - Foobar2000 meets the iPod

Reply #1291 –
Quote
Quote
would be nice if the plugin checked the available space before copying. also,

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.[a href="index.php?act=findpost&pid=288716"][{POST_SNAPBACK}][/a]

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.

foo_pod - Foobar2000 meets the iPod

Reply #1292 –
Quote
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.

foo_pod - Foobar2000 meets the iPod

Reply #1293 –
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

foo_pod - Foobar2000 meets the iPod

Reply #1294 –
Quote
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.
[a href="index.php?act=findpost&pid=288759"][{POST_SNAPBACK}][/a]

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.

foo_pod - Foobar2000 meets the iPod

Reply #1295 –
Quote
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.

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:
Code: [Select]
Add         Delete         Replace           Song

                   x                                    Song Artist - Title #1
   x                                                    Song Artist - Title #2
                                       x                Song Artist - Title #3

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...

foo_pod - Foobar2000 meets the iPod

Reply #1296 –
Quote
Yeah, that would be a really useful feature to add to sync.
Glad you agree.
Quote
I don't think the Foobar console is really up to the task, though.
A txt file would be perfect for my needs.
Quote
What would be cool is a vertically scrollable window, with 3 checkboxes (add, delete, replace) followed by the song name/filename.
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

foo_pod - Foobar2000 meets the iPod

Reply #1297 –
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.

foo_pod - Foobar2000 meets the iPod

Reply #1298 –
Quote
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.

foo_pod - Foobar2000 meets the iPod

Reply #1299 –
Quote
What would be cool is a vertically scrollable window, with 3 checkboxes (add, delete, replace) followed by the song name/filename.
[a href="index.php?act=findpost&pid=289067"][{POST_SNAPBACK}][/a]

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!