[Bug-gnupod] Re: problem with gnupod
I guess you can disregard the last message I sent. I was able to get around this problem by setting the serial number via --fwguid. --- On Sun, 5/10/09, Adam Petcher wrote: > From: Adam Petcher > Subject: problem with gnupod > To: bug-gnupod@nongnu.org > Date: Sunday, May 10, 2009, 2:22 PM > I'm having some trouble getting gnupod to work. The > problem is that any time mktunes, it hangs on > "Searching iPod via sysfs". I've let it go > for a few hours and nothing happens, so I am assuming it > will hang forever. I've tried restoring the iPod in > iTunes, and I even tried formatting the ipod and then > calling gnupod_INIT -- either way, it just hangs the first > time mktunes is called. Here are the details: > > gnupod 0.99.7 > iPod Classic 80 GB > Ubuntu 9.04 (jaunty) > > I don't really know what other info would help. The > problem comes up whether the database is empty, contains a > couple of songs, or contains my entire library. Let me know > if there is any other info that will help. ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
[Bug-gnupod] problem with gnupod
I'm having some trouble getting gnupod to work. The problem is that any time mktunes, it hangs on "Searching iPod via sysfs". I've let it go for a few hours and nothing happens, so I am assuming it will hang forever. I've tried restoring the iPod in iTunes, and I even tried formatting the ipod and then calling gnupod_INIT -- either way, it just hangs the first time mktunes is called. Here are the details: gnupod 0.99.7 iPod Classic 80 GB Ubuntu 9.04 (jaunty) I don't really know what other info would help. The problem comes up whether the database is empty, contains a couple of songs, or contains my entire library. Let me know if there is any other info that will help. ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] DESC field in iTunesDB / lyrics display
On Sun, May 10, 2009 at 06:15:12PM +0200, Richard van den Berg wrote: > On 5/10/09 6:00 PM, Richard van den Berg wrote: >> What do you mean by "all the time"? My iPod shows the artwork during >> the volume and position display, but not during the rating one. >> > > I just checked, and the artwork is also showing during the rating view. > The "artwork view" on my iPod shows the artwork fullscreen, and > presumably you can browse through multiple artwork images if present in > the file (I don't have such files). My ipod doesn't have a separate artwork view. -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] DESC field in iTunesDB / lyrics display
On Sun, May 10, 2009 at 06:00:08PM +0200, Richard van den Berg wrote: > On 5/9/09 5:04 PM, H. Langos wrote: >> Are you sure that the postings you've read about lyrics display where >> talking about your model? >> > > Yes. http://forums.macrumors.com/showthread.php?t=160916 suggests that > the iPod reads the lyrics from the mp3 and not the iTunesDB. That would > explain why my test failed. I only set the lyrics_flag, but did not add > a USLT tag. I can confirm that iTunes also adds a USLT tag when you add > lyrics to an mp3. > > I just did another test with 2 files with USLT tags. When the > lyrics_flag is 0, no lyrics are shown. When it is 1, the lyrics are > shown! So gnupod should really set the lyrics_flag when a USLT is > present in mp3 files. Cool, I'll try that on my iPod. > This also means that filling the description field with the USLT info > for non-podcast mp3s is pretty useless. I don't have enough experience > with podcasts to check if the description field or USLT tag is shown for > those files. It is the "desc" attribute. I worked with podcast files that had the ULT tag though (id3v2.0 predecessor of USLT). I didn't have a file with USLT tag to test yet but for podcasts I can assure you that the content of the "desc" attribute is shown. cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] Patch to support ReplayGain / mp3gain
On Sun, May 10, 2009 at 10:35:57AM +0200, Richard van den Berg wrote:
> On 5/10/09 1:35 AM, H. Langos wrote:
>> I guess we should go this way:
>>
>> 1. Use RVA2/XRVA or (if the former is missing) REPLAY_GAIN_x to compute a
>>new "soundcheck" value.
>>
>> If the first step didn't yield any information: 2. Use iTunNORM's
>> "soundcheck" value and RVA "volume" adjustment.
>>
>> This would probably work for most people.
>>
>
> Agreed. All we really need to make this happen is a parsing of the RVAD
> tag that iTunes creates for the volume adjustment.
I guess I can take care of that this week. Could you send me a short
mp3 with manualy adjusted volume to different levels? The shortes mp3 you
have should do. I just need it in different versions. One version with
-100% adjustment, one with 0, one with +50% and one with +100%.
I have a pretty good idea now how iTunes stores it in the RVAD tag but I'd
like some real samples to confirm.
> For the rest I can write the code myself. ;-)
Go for it! :-)
> Do you want to wait until we have a all of the above working before you
> commit my current ReplayGain patches to CVS?
I hope I get around to commit those changes tomorrow.
>>> I just checked and MP3::Info returns each TXXX tag as an individual
>>> value (not a hash). So TXXX:replaygain_track_gain="-2 dB" becomes
>>> $hs{REPLAYGAIN_TRACK_GAIN}="-2 dB". This means the TXXX tags
>>> overwrite the APE ReplayGain tags by default. I just tested this,
>>> and it works; when ReplayGain data is set differently in the APE tag
>>> and TXXX tag, the TXXX is used by gnupod. Sweet.
>>>
>>
>> Great. Did you check if that works with the parameters that FileMagic.pm uses
>> for its get_mp3tag() call?
>>
>
> Yes. I tested this with an actual mp3 and the CVS version of gnupod with
> my patches applied. It worked without additional modifications.
Great!
BTW: I just took a look at my collection to see what I've got to play with...
That iTunNORM comments are stranger than I thought. Browsing through the
tags of my collection I've found what I can probably best describe as two
distinct "populations" of them.
One that group has rather high values
|'COM' => [
| {
| 'iTunNORM' => ' 036E 0346 38E3 3948 00081667
00081667 8000 8000 002EFF85 00153
| },
| 'www.DJRiver.com - Official Site.^@'
| ],
and one that show _very_ low values:
| 'iTunNORM' => ' 0028 0054 148A 1CCD ...
which translates to something like +14dB.
There is even a couple of files that have two iTunNORM tags. One in the
ordinary COMM tag and one in a TXXX tag. But what is realy freaky is that
those two tags differ:
|'COMM' => [
|{
| 'iTunNORM' => ' 004B 0090 011B 0206 7547
000186E5 203C 2AA5 00038287 0003
|},
|' YEAR: 2004^@'
| ],
|'ITUNNORM' => '005D 00B8 027F 03FF 00034608 0001D991 2BF7
393E 0003487E 000336C6',
What a mess :-)
I didn't see any RVA tags but that may be because my tag reader is
ignoring them. I'll have to check manualy. If in doubt .. use hexdump -C :-)
cheers
-henrik
___
Bug-gnupod mailing list
Bug-gnupod@nongnu.org
http://lists.nongnu.org/mailman/listinfo/bug-gnupod
[Bug-gnupod] gnupod_addsong.pl --artwork without ImageMagick
I just ran into an interesting issue when running "gnupod_addsong.pl --artwork x.jpg *.mp3" on a system without ImageMagick present. The configure script warned me that artwork would not work, but my add shell script used it anyway. The adding of the songs worked (the are in the XML and can be played on the iPod), but for each mp3 gnupod_addsong.pl told me it was skipping the file because it was a duplicate. So strange. The artwork on the iPod showed a black image (no surprise there). $ adddirtoipod . gnupod_addsong.pl Version 0.99.8 -CVS (C) Adrian Ulrich ! [] './Jesse Dee/Bittersweet Batch/Jesse Dee - 01 - Alright.mp3' is a duplicate of song 4676, skipping file ! [] './Jesse Dee/Bittersweet Batch/Jesse Dee - 02 - Around Here.mp3' is a duplicate of song 4677, skipping file ! [] './Jesse Dee/Bittersweet Batch/Jesse Dee - 03 - Slow Down.mp3' is a duplicate of song 4678, skipping file ! [] './Jesse Dee/Bittersweet Batch/Jesse Dee - 04 - Over & Over Again.mp3' is a duplicate of song 4679, skipping file ! [] './Jesse Dee/Bittersweet Batch/Jesse Dee - 05 - My Two Feet.mp3' is a duplicate of song 4680, skipping file ! [] './Jesse Dee/Bittersweet Batch/Jesse Dee - 06 - Remember Me.mp3' is a duplicate of song 4681, skipping file ! [] './Jesse Dee/Bittersweet Batch/Jesse Dee - 07 - Reap What You Sow.mp3' is a duplicate of song 4682, skipping file ! [] './Jesse Dee/Bittersweet Batch/Jesse Dee - 08 - Yet To Come.mp3' is a duplicate of song 4683, skipping file ! [] './Jesse Dee/Bittersweet Batch/Jesse Dee - 09 - New Blades Of Grass.mp3' is a duplicate of song 4684, skipping file ! [] './Jesse Dee/Bittersweet Batch/Jesse Dee - 10 - Still Here.mp3' is a duplicate of song 4685, skipping file ! [] './Jesse Dee/Bittersweet Batch/Jesse Dee - 11 - Alive & Kickin.mp3' is a duplicate of song 4686, skipping file ! [] './Jesse Dee/Bittersweet Batch/Jesse Dee - 12 - Slow Down (Remind).mp3' is a duplicate of song 4687, skipping file > Updating ArtworkDB Done I looked at the code for gnupod_addsong.pl but could not find the cause for this behaviour. Installing ImageMagick of course fixed the issue. Cheers, Richard ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] DESC field in iTunesDB / lyrics display
On 5/10/09 6:00 PM, Richard van den Berg wrote: What do you mean by "all the time"? My iPod shows the artwork during the volume and position display, but not during the rating one. I just checked, and the artwork is also showing during the rating view. The "artwork view" on my iPod shows the artwork fullscreen, and presumably you can browse through multiple artwork images if present in the file (I don't have such files). Cheers, Richard ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] DESC field in iTunesDB / lyrics display
On 5/9/09 5:04 PM, H. Langos wrote: Thats pretty close to what I use (iPod nano (3rd generation)) but since artwork is displayed all the time, there is no separate cycle position for it. What do you mean by "all the time"? My iPod shows the artwork during the volume and position display, but not during the rating one. Are you sure that the postings you've read about lyrics display where talking about your model? Yes. http://forums.macrumors.com/showthread.php?t=160916 suggests that the iPod reads the lyrics from the mp3 and not the iTunesDB. That would explain why my test failed. I only set the lyrics_flag, but did not add a USLT tag. I can confirm that iTunes also adds a USLT tag when you add lyrics to an mp3. I just did another test with 2 files with USLT tags. When the lyrics_flag is 0, no lyrics are shown. When it is 1, the lyrics are shown! So gnupod should really set the lyrics_flag when a USLT is present in mp3 files. This also means that filling the description field with the USLT info for non-podcast mp3s is pretty useless. I don't have enough experience with podcasts to check if the description field or USLT tag is shown for those files. Cheers, Richard ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] Patch to support ReplayGain / mp3gain
On 5/10/09 1:35 AM, H. Langos wrote:
I guess we should go this way:
1. Use RVA2/XRVA or (if the former is missing) REPLAY_GAIN_x to compute a
new "soundcheck" value.
If the first step didn't yield any information:
2. Use iTunNORM's "soundcheck" value and RVA "volume" adjustment.
This would probably work for most people.
Agreed. All we really need to make this happen is a parsing of the RVAD
tag that iTunes creates for the volume adjustment. For the rest I can
write the code myself. ;-)
Do you want to wait until we have a all of the above working before you
commit my current ReplayGain patches to CVS?
I just checked and MP3::Info returns each TXXX tag as an individual
value (not a hash). So TXXX:replaygain_track_gain="-2 dB" becomes
$hs{REPLAYGAIN_TRACK_GAIN}="-2 dB". This means the TXXX tags overwrite
the APE ReplayGain tags by default. I just tested this, and it works;
when ReplayGain data is set differently in the APE tag and TXXX tag, the
TXXX is used by gnupod. Sweet.
Great. Did you check if that works with the parameters that FileMagic.pm uses
for its get_mp3tag() call?
Yes. I tested this with an actual mp3 and the CVS version of gnupod with
my patches applied. It worked without additional modifications.
Cheers,
Richard
___
Bug-gnupod mailing list
Bug-gnupod@nongnu.org
http://lists.nongnu.org/mailman/listinfo/bug-gnupod
