[Bug-gnupod] GNUpod 0.98.8 released
Hi there, To people subscribed to the list this is not really news but for the sake of completeness I'll post it here, too. As announced last month the new GNUpod release 0.99.8 is done. The download mirrors already contain gnupod-0.99.8.tgz. This release is mostly a bugfix release. Ubuntu users in particular should no longer see mktunes hanging on auto detection of the fwguid and 4gen nano users will enjoy complete artwork support. There are only a few new features. Most notably the Replay Gain handling has been completely reworked. As always the changes are listed in the CHANGES file: http://git.savannah.gnu.org/cgit/gnupod.git/tree/CHANGES?h=releases/0.99.8id=release-0_99_8 For the truly curious here is a coloured diff between the 0.99.7 and 0.99.8: http://git.savannah.gnu.org/cgit/gnupod.git/diff/?h=releases/0.99.8id=releases/0.99.8id2=9721afa97a049bed7ed3afa4ec4c8bf725db0c8b cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] iPod touch / iPhone artwork
Hi Roger, As far as I know there's nobody right now working on the artwork code and that code realy needs some love and care. You are most welcome to get your hands dirty there :-) The only thing I did with artwork in gnupod was to add artwork support for podcasts and some refinement on the extractArtwork.pl tool. The drop key seems to be used where in libgpod the crop value is set to true. Currently gnupod has no notion of RGB555 format and of padding the graphics to a certain size. Both seems te be required judging from libgnupod's itdb_device.c : http://gtkpod.svn.sourceforge.net/viewvc/gtkpod/libgpod/trunk/src/itdb_device.c?view=markup But the graphics profiles can easily be extended by some hash keys like format='THUMB_FORMAT_RGB565_LE' and padding=8192 I assume you are using the git repository so you can easily follow development and send patches upstream. As far as the distorted images go I'd guess that this comes from not aligning the images to 8192 or 16384 block borders (there seems to be a typo in the libgpod saying 16364 instead). Cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] Duplicate Song Added
Hi Dave, On Sun, Jul 26, 2009 at 08:50:06PM -0400, Dave Jarvis wrote: 6. gnupod_INIT.pl -m /media/ipod 7. gnupod_search.pl -m /media/ipod -a Belvedere Results: ID |ARTIST |ALBUM |TITLE ... 3048|The Belvedere Broadcasters |Authentic Arrangements |Tain't No Sin ... Then: 1. sudo gnupod_addsong.pl -m $IPOD_MOUNTPOINT Taint_No_Sin.mp3 *Expected Results* The song should have been detected as a duplicate. *Actual Results* The song was added. Thanks for the bug report. I'm in the middle of moving house so here's just a quick idea. The detection of duplicates (for non-converted and non-podcast items) is based soly on the attributes title, bitrate, time, and filesize. Are you absolutely sure that you are adding the same file again? Not a differently encoded version of it. Or one from a single where the sound engineer left a couple more seconds of silence at the endi than at the album version? Even changing id3 tags can often lead to a change in filesize and thus make it look like a different song. Try this to find the actual difference: $ grep No Sin $IPOD_MOUNTPOINT/iPod_Control/.gnupod/GNUtunesDB.xml | less -S Cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
[Bug-gnupod] release 0.99.8 nearing completion
Hi, After almost a year it is time to prepare a new release. It is almost done and a current snapshot of the 0.99.8 development can be downloaded here: http://git.savannah.gnu.org/cgit/gnupod.git/snapshot/gnupod-releases/0.99.8.tar.gz This release is mostly a bugfix release. Ubuntu users in particular should no longer see mktunes hanging on auto detection of the fwguid and 4gen nano users will enjoy complete artwork support. There are only a few new features. Most notably the Replay Gain handling has been completely reworked. Unless somebody finds a grave bug we will release the next version soon with the CHANGES mentioned here: http://git.savannah.gnu.org/cgit/gnupod.git/tree/CHANGES?h=releases/0.99.8 For the truly curious here is a coloured diff between the 0.99.7 and 0.99.8: http://git.savannah.gnu.org/cgit/gnupod.git/diff/?h=releases/0.99.8id=releases/0.99.8id2=9721afa97a049bed7ed3afa4ec4c8bf725db0c8b @Adrian: Do you think you can find time to publish that release? I'd like to have it out of the door ASAP because the current release is almost unusable on ubuntu systems. cheers -henrik PS: Work on the new shuffle support is going slow because I have a lot of other stuff on my TODO list. (Moving into new apartment these days.) ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] release 0.99.8 nearing completion
Hi J. On Tue, Jul 14, 2009 at 10:19:43PM +1000, Jacinta Richardson wrote: H. Langos wrote: This release is mostly a bugfix release. Ubuntu users in particular should no longer see mktunes hanging on auto detection of the fwguid and 4gen nano users will enjoy complete artwork support. Will the documentation I provided or something like it be added? I couldn't spot it in a cursory glance over the coloured diff. Sorry, but I delayed that to the next release. Moving the documentation into the perl files required some changes to the build/install mechanics of gnupod. Those changes triggered some even deeper changes to the build process that are not yet complete. Your changes are however in the master branch and will be in the next release after 0.99.8. Here's the diff from 0.99.8 to master (I'll merge the changes to the CHANGES file back into master as soon as the 0.99.8 release is out.) http://git.savannah.gnu.org/cgit/gnupod.git/diff/?h=masterid=masterid2=releases/0.99.8 Cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] release 0.99.8 nearing completion
On Wed, Jul 15, 2009 at 01:21:06AM +1000, Jacinta Richardson wrote: H. Langos wrote: Sorry, but I delayed that to the next release. Moving the documentation into the perl files required some changes to the build/install mechanics of gnupod. Those changes triggered some even deeper changes to the build process that are not yet complete. Making the documents the primary documentation would. I can see that. However merely adding it in to the .pm files themselves shouldn't require any build process changes. I didn't want yet another place for the documentation. Thats why I wanted to add the new and remove the old at the same time. Still, I agree that getting the bug fixes out as soon as possible is a noble goal, and the new documentation should probably be careful reviewed before being stamped as official. As careful as I can. :) Your changes are however in the master branch and will be in the next release after 0.99.8. Do you have an anticipated release date? For 0.99.8? As soon as I can get Adrian to do it. :-) For the next one after that? Dunno, I'll go to Brasil for a couple of month this winter to visit family. Maybe I'll have a some time for gnupod in the evenings and maybe I can even get the local school connected to the next city via a wireless link. I hear that they already have all the equipment there and only need somebody to install and configure it but in brasil it's always more difficult than that. :-) cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] Support for 4th gen iPod Shuffle
Hi gnupod gang, On Tue, Jun 30, 2009 at 12:16:28AM +0200, H. Langos wrote: The nice people at Automazic are lending me a 4gen iPod shuffle, so that I can take a look at the iTunesSD format and even verify whatever we find out. Yesterday the ipod arrived. I hope I'll manage to do some basic installation tonight and maybe even first testis to fill in the blank spaces in our knowledge of the shuffle format. In order to document our findings and make them accessible to everybody else I've started a wiki here: http://shuffle3db.wikispaces.com/ Everybody is invited to join the effort and add their piece of knowledge. BTW: I am conflicted about the usage of 4th/3rd generation. Usually I'd stick with the libgpod/gtkpod numbering and call it 4th generation but most users will go with the manufacturers name. Any thoughts? cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] Configure as_echo fix
On Fri, Jul 03, 2009 at 08:37:20PM +0200, Richard van den Berg wrote: Configure has always printed -n strings on my MacBook. I fixed that by using as_echo and as_echo_n. See my patch on the rvdb/configure-fix branch. Looks good so far. I'll merge it. It's probably a shell oddity of the echo builtin. Which mac os version did you use? The default Mac OS X sh was originally Zsh; it was changed to Bash in Mac OS X 10.2. Do you happen to know if AC_MSG_CHECKING, AC_MSG_RESULT, and AC_MSG_NOTICE are posix ? cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] Text::CharWidth
Hi Richard, On Fri, Jul 03, 2009 at 09:16:41PM +0200, Richard van den Berg wrote: There is no test for Text::CharWidth in configure required by gnupod-delete. I'm not sure if it should be a required or an optional module. Actually it is FindHelper's prettyprint function and the same problem will arise in gnupof_find. I could workaround it more or less by disabling that code path if Text::CharWidth is not installed but it would cause the output to be wrongly formated (as by gnupod_search when printing non-ascii utf8 characters). It would be easier to simply require Text::CharWidth but I guess there's enough ppl who will never have an accented character in their mp3 collection. If you want to fix it yourself take a look at the code that handles Date::Manip in FindHelper. cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] Configure as_echo fix
On Fri, Jul 03, 2009 at 10:06:58PM +0200, Richard van den Berg wrote: On 7/3/09 9:59 PM, H. Langos wrote: Which mac os version did you use? OS X 10.5.7 The default Mac OS X sh was originally Zsh; it was changed to Bash in Mac OS X 10.2. I definitely use bash. If it wasn't the default, I would have changed it. :-) I use bash most of the time too. But I try not to rely on bashisms. Do you happen to know if AC_MSG_CHECKING, AC_MSG_RESULT, and AC_MSG_NOTICE are posix ? I'm not sure what you mean by them being posix, but they should be platform independent. I wanted to know if they are specific to gnu autoconf or if they are defined in the POSIX standard. But it seems that autoconf itself is not covered by the posix standard. Instead autoconf is defined by it's implementation (and its version specific bugs ;) Soo... if you feel like changing it to those macros, go for it. But I would probably not waste too much time on it. Where did you find the hint to replace echo $ECHO_N by $as_echo_n? cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] artwork support apparently (but not really) broken on ubuntu
Hi Chris, On Thu, Jul 02, 2009 at 07:03:21AM +0200, chris.com wrote: Hello Henrik, The behaviour is not intended as you so nicely put it. It is/was a bug and has been corrected in the 6.4.9-9 version. From the ChangeLog: 2009-03-01 6.4.9-9 Cristy quetzlzacatena...@image... * Convert returns MagickFalse for the -version option (reference http://www.imagemagick.org/discourse-server/viewtopic.php?f=2t=13230). Thats good news. So I'll let this pass and I'll not invest any time into working around it. I think conversion -version is a correct way to check whether ImageMagick is installed. autoconf contains a macro AC_PATH_PROG that checks the existence of the executable But there is no predefined macro as far as I can see that checks whether a particular version is installed Every program reports its version in a different format, so there is no standard way of checking for a version. At least no way that would work on different Linux distributions, let alone different Unix versions. However I haven't been able to figure out what to do with the IMAGIC variable. It seems indeed unused elsewhere. I'll try to figure that out next Don't bother.. it realy isn't used anywhere else. There's only the check and the output in configure.ac which is translated by autoconf into the configure script. But if we ever decide to improve the error handling or even decide to change the code according to autoconf's findings, it's good to know that we should be able to rely on convert -version. Thank you very much for the research. cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] mktunes.pl creates corrupt iTunesDB ?
G'day J,
Thank you very much for the examples and the insights.
It's good to know that I'm not completely off with my
novice's views of code style.
On Thu, Jul 02, 2009 at 10:30:04AM +1000, Jacinta Richardson wrote:
This practice is called named arguments and is a great way of calling
subroutines because it removes the confusion of which order the arguments need
to go in. It also allows you to set and use defaults, for example:
I hadn't looked at it from the angle of providing defaults. But it looks
very intuitive and robust. Until now I had defaults assigned one by one
to my variables in sub routines and then optionally overwritten by the
arguments passed in the $args_ref. Assigning them in one go is way more
elegant.
state %defaults = ( # 5.10+ only, else my %defaults
foo = 'a', # or a closure
bar = 'b',
);
state seems more or less equivalent to static in C. Nice feature.
$args_ref = { %defaults, %{$args_ref} };
I hadn't tought of that way to merge hashes. I wonder if it is usable for
subroutines that are called very often or if unrolling both hashes and
merging them this way is slower than conditionally assigning one by one.
my $foo = 'a';
my $bar = 'b';
$foo = $args_ref-{foo} if defined($args_ref-{foo});
My first guess would be that merging the hashes is faster for bigger numbers
of arguments but slower if you are dealing with only a couple of arguments.
Anyway, I'll try both when the occasion arises and see what the profiler
has to say.
It's not discussed in perlstyle, and perlsub because the maintainers of those
files haven't really decided on a one-true way, or because they've been too
lazy
to write it... Damian Conway wrote bunch of good ideas about good Perl style
in
his book called Perl Best Practices, which is what most people point to when
they talk about Perl style now. These practices have been turned into
requirements by the Perl::Critic system too, so you can get automated feedback
on your code quality by using the Perl::Critic programs.
Thats a very good pointer. I'll try and see what Perl::Critic has to say about
the code in gnupod.
Hope this helps.
A lot! Thank you very much.
cheers
-henrik
___
Bug-gnupod mailing list
Bug-gnupod@nongnu.org
http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] mktunes.pl creates corrupt iTunesDB ?
Hi Richard, On Wed, Jul 01, 2009 at 04:57:14PM +0200, Richard van den Berg wrote: On Wed, July 1, 2009 16:13, Jacinta Richardson wrote: I suspect it's a matter of laziness. I claim ignorance. I didn't know there was a fundamental difference between the two ways of calling a subroutine. Thanks for the explanation. I'd suggest applying the patch with this tidied up as appropriate. Done. Could you check if it still does what it was is supposed to do? :-) I merged the low_ram branch into master yesterday evening but I wanted to sleep over it before commiting. Here are the changes that actually happend to master: git diff 94462eb 25a4d8b or http://git.savannah.gnu.org/cgit/gnupod.git/commit/?id=25a4d8ba6a080589577abc20db7587a18b1cade9 It was a bit tricky as the previous merges on low_ram made parts of the changes in master look outdated eventhough they were more current than than in low_ram. I hope I didn't mess it up completely. :-) It may be better to avoid merges among branches. rather -o---o---o---o---o---o---o master \ \ \ / / o o---o---o / topic a \ / o---o---o---o---o topic b than -o---o---o---o---o---o---o master \ \ \ / / o o---o---o / topic a \ \ / o---o---o---o---o topic b Also, if you need to merge several branches into one, I suggest the usage of octopus merges instead of merging step by step. But I'm no git guru. So don't take my word for it. cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
[Bug-gnupod] The docs are dead! Long live the docs! ;-)
Hi there, Some minutes ago the doc branch was merged. Man pages are gone. Now there's the pod style documentation within the perl files. Not all of them but if somebody writes up an undocument mock up, there's an include mechanism that will allow to add it with a single line to the script files that don't have their own documentation yet. Hopefully this will be easier to maintain. Apart from that, there is the info documentation that I don't really know how to maintain. Volunteers welcome :-) While working on the documentation, I took a look at the build system and decided that it should be more modular than just make install. Currently you can't really test your changes unless you install the whole thing. Now there is a rudimentary build step where scripts, modules and documentation are rendered into a separate directory where you can run them before you decide to call make install as root. It is rudimentary in many regards but it's a start. I want to get the functions of tools/gnupod_install.pl step by step out of there and into the Makefile/configure script. gnupod_install.pl should only prepare the files, do some substitutions and leave the real installation to standard posix tools like cp and chmod or maybe install. (BTW: Is install a posix tool?) Along the way I want to a) make it configurable if you keep the .pl extension on the installed perl scripts (and their man pages) or if you'd rather strip them. (I'd rather strip the .pl but that's a matter of taste and I will not fight about it.) b) make the target directory for the gnupod modules configurable via ./configure (I don't like the way gnupod messes around in /etc to install its modules.) c) Insert your wish here ;-) cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] mktunes.pl creates corrupt iTunesDB ?
Hi Richard,
On Fri, Jun 19, 2009 at 08:26:30PM +0200, Richard van den Berg wrote:
On 6/19/09 11:07 AM, H. Langos wrote:
Maybe the merge code should only be active if your memory saving feature is
active?
Here is the new patch that does just that. I love git, it's super fast. :-)
One more question:
Why did you use
resetxml;
instead of
resetxml();
?
I know the former doesn't pass an empty @_ array for the called sub but
passes the existing argument list. But you don't do anything with @_ in
resetxml(). So why bother passing the current arguments list on to it?
cheers
-henrik
diff --git a/src/ext/XMLhelper.pm b/src/ext/XMLhelper.pm
index 748ce22..bb7c88b 100755
--- a/src/ext/XMLhelper.pm
+++ b/src/ext/XMLhelper.pm
@@ -301,19 +301,23 @@ sub mkh {
}
-
#
-# Parses the XML File and do events
-sub doxml {
- my($xmlin, %opts) = @_;
- return undef unless (-r $xmlin);
- ### reset some stuff if we do a second run
+# Reset some stuff if we do a second run
+sub resetxml {
$cpn = undef; #Current PlaylistName
@idpub = ();
@plorder = ();
$xid = 1;
$XDAT = undef;
- ###
+}
+
+
+#
+# Parses the XML File and do events
+sub doxml {
+ my($xmlin, %opts) = @_;
+ return undef unless (-r $xmlin);
+ resetxml;
my $p;
my $ref = eval {
$p = new XML::Parser(ErrorContext = 0,
Handlers={Start=\eventer});
___
Bug-gnupod mailing list
Bug-gnupod@nongnu.org
http://lists.nongnu.org/mailman/listinfo/bug-gnupod
[Bug-gnupod] artwork support apparently (but not really) broken on ubuntu
GNUpod's configure script tries to run convert --version and checks the returncode to determine if convert from imagemagick is installed. This (accidentially) works as convert accepts --version eventhough the correct option would be -version. On Debian both commands return with 0, which for configure means OK. $ convert -version ; echo $? Version: ImageMagick 6.3.7 12/10/08 Q16 http://www.imagemagick.org Copyright: Copyright (C) 1999-2008 ImageMagick Studio LLC 0 $ convert --version ; echo $? Version: ImageMagick 6.3.7 12/10/08 Q16 http://www.imagemagick.org Copyright: Copyright (C) 1999-2008 ImageMagick Studio LLC 0 Apparently imagemagick 6.4 on ubuntu 9.04 prefers not to be detected that way. Eventhough this version also accepts --version and -version, the return code in both cases is 1. u...@user-desktop:~/idm$ convert -version ; echo $? Version: ImageMagick 6.4.5 2009-01-22 Q16 OpenMP http://www.imagemagick.org Copyright: Copyright (C) 1999-2008 ImageMagick Studio LLC 1 u...@user-desktop:~/idm$ convert --version ; echo $? Version: ImageMagick 6.4.5 2009-01-22 Q16 OpenMP http://www.imagemagick.org Copyright: Copyright (C) 1999-2008 ImageMagick Studio LLC 1 This leads configure to the assumption that something is broken and therefore artwork would not work. But as far as I've looked into the code, this finding is not used anywhere in the code. So artwork operations will still be tried and will work as long as imagemagick is installed. Somebody should get in touch with the imagemagic developers and try to find out if that is intended behavior or just an oversight. Volunteers? cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] artwork support apparently (but not really) broken on ubuntu
Hi Chris, On Tue, Jun 30, 2009 at 11:08:58PM +0200, chris.com wrote: H. Langos wrote: GNUpod's configure script tries to run convert --version and checks the returncode to determine if convert from imagemagick is installed. This (accidentially) works as convert accepts --version eventhough the correct option would be -version. On Debian both commands return with 0, which for configure means OK. Apparently imagemagick 6.4 on ubuntu 9.04 prefers not to be detected that way. Eventhough this version also accepts --version and -version, the return code in both cases is 1. This leads configure to the assumption that something is broken and therefore artwork would not work. But as far as I've looked into the code, this finding is not used anywhere in the code. So artwork operations will still be tried and will work as long as imagemagick is installed. Somebody should get in touch with the imagemagic developers and try to find out if that is intended behavior or just an oversight. I'll contact them When you say 'this finding is not used anywhere' what doe you mean with this finding? The return code or the version? With this finding I ment configure's assumption that imagemagick was not installed and that gnupod's artwork support would not work, based on the different return code of convert --version. As far as I've traced the gnupod configure script, it only sets the variable IMAGIC to No (ImageMagick is not installed) and the varible IMAGIC is printed at the end of the configure script. No changes in the actual gnupod code are made. No matter if IMAGIC is set to :-) If you are curious here's the configure.ac code: http://git.savannah.gnu.org/cgit/gnupod.git/tree/configure.ac cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Fwd: Re: [Bug-gnupod] SoundCheck/ReplayGain]
Hi chris, On Mon, Jun 22, 2009 at 10:49:13PM +0200, chris.com wrote: Henrik, H. Langos wrote: On Mon, Jun 22, 2009 at 12:05:09AM +0200, chris.com wrote: Hello Henrik, Do you want me to load a 130 firmware and send you the iTunesSD? That would be great. Could you find out when that firmware was released? Well here it is. I loaded the 130 firmware and loaded with iTunes the 9 songs I sent earlier. And does it adjust the volume according to the data in your iTunesSD's new format? Well yes. It codes it exactly the same way as with the most recent firmware. Btw I used the www.blinkenlights.ch firmware instruction I wrote the firmware to a not existing device node: /dev/sdb1 Writing to it made the device visible and I has able to read the (same) firmware from it. But otherwise the device node is invisible and can't be mounted. I checked with fdisk what kind of disk it is but it's very confused about it: This doesn't look like a partition table Probably you selected the wrong device. Well, I don't have a suffle yet but I hope I cann borrow one these days. That will make it easier to test things. Anything I can do for you? chris I finally got hold of an old 1gen shuffle and even there the new format gets accepted. So I'll simply switch to the new format as soon as I find the time to implement it. I'll leave the old behavior in there as an option but the new one will be the default. cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] Re: problem with gnupod
On Sun, Jun 21, 2009 at 01:42:19PM +1000, Jacinta Richardson wrote: H. Langos wrote: Hi Adam, As you already figured out, the trouble was caused by gnupod trying to find the devices serial number (aka fwid). The problem is that gnupod used a rather crude way to look for the device in /sys/block and ubuntu has recently made some big changes there. The problem you describe has been reported before: http://lists.gnu.org/archive/html/bug-gnupod/2009-04/msg3.html It would be great if you could check out the current CVS version of gnupod to see if it works any better: sudo su - apt-get remove gnupod-tools apt-get -y install cvs apt-get -y install autoconf cvs -z3 -d:pserver:anonym...@cvs.savannah.gnu.org:/sources/gnupod co gnupod cd gnupod autoconf ./configure make intall I can confirm that this version does fix the mktunes.pl problem. Great! Thank you. cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] Documentation
G'day J, You took the words right out of my mind! Documentaion should stay as close as possible to the source. I've been submitting patches to gnupod_addsong for month before even learing that there was a man page that needed to be updated to reflect the changes that I had made.. I'll try to merge your documentation tomorrow. Thank you very much! It would be awesome if we could improve the documentation to show how to add videos and TV Shows, but I'm not 100% sure that gnupod_addsong could handle that yet. It does handle videos but it isn't very good at giving them the right attributes. I've written some stuff from scratch like gnupod_find and gnupod_delete to replace gnupod_search. The next thing will be gnupod_modify to finally be able to modify all attributes but before I start a rewrite of gnupod_add I want to find a good sustainable coding style for perl. It would be great if you could join that discussion. cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
[Bug-gnupod] gnupod moved from CVS to GIT...
...and the people rejoiced. Now everybody can get a piece of gnupod by running git clone git://git.savannah.gnu.org/gnupod.git This creates a gnupod sub directory with the current bleeding edge development version of gnupod. One more autoconf configure make install and you've got it installed. Please uninstall a previous version of gnupod if you installed it from your distribution's packet management system (in Ubuntu and Debian the packet is called gnupod-tools) as the paths for installing perl modules might differ and you may end up with two installed versions of some gnupod modules and executables. An now some more details for the curious: In that gnupod directory will be a .git subdirectory with the complete gnupod history (every revision, every patch, every tag, everything.) so every lookup of past versions and diffs will happen locally. No need for connectivity, NO latency! Instead of explaining it all wrong here's the synopsis of git-clone Clones a repository into a newly created directory, creates remote-tracking branches for each branch in the cloned repository (visible using git branch -r), and creates and checks out an initial branch equal to the cloned repository´s currently active branch. After the clone, a plain git fetch without arguments will update all the remote-tracking branches, and a git pull without arguments will in addition merge the remote master branch into the current master branch, if any. This default configuration is achieved by creating references to the remote branch heads under $GIT_DIR/refs/remotes/origin and by initializing remote.origin.url and remote.origin.fetch configuration variables. For beginners a gui is always nice to get a feeling gitk or qgit There's tons of good git tutoruials and migration guides for people who are familiare with other version control systemss so I'll only recommend reading the man pages git-tutorial and git-workflows: http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] mktunes.pl creates corrupt iTunesDB ?
Hi Richard,
On Wed, Jun 17, 2009 at 10:00:16PM +0200, Richard van den Berg wrote:
On 6/17/09 10:41 AM, H. Langos wrote:
- $mktunes-WriteItunesDB;
+ $mktunes-WriteItunesDB(Keep=$opts{'keepattr'});
Shouldn't that be :
$mktunes-WriteItunesDB( {Keep = $opts{'keepattr'}} );
It turns out it depends on your usage. The form I chose you can used as:
($self,%args) = @_;
@keep=split(/[ ,]+/, $args{Keep});
This form passes the whole hash as a key/value list and creates a new one in
the sub. It will break if you add other parameters as the receiving %args
hash will try to suck up all he parameters that you pass.
$mktunes-WriteItunesDB(Keep=$opts{'keepattr'},foo,bar);
will let foo and bar end up in %args:
You might try to separate them but
($self,%args,$localfoo,$localbar) = @_;
will end up
%args == ( Keep = value of $opts{'keepattr'},
foo = bar )
$localfoo == undef
$localbar == undef
While the form with the {} can be used as:
($self,$args) = @_;
@keep=split(/[ ,]+/, $args-{Keep});
This form only passed a single hash reference.
thus
($self,$args,$localfoo,$localbar) = @_;
will assign a single scalar to $args and $localfoo and $localbar will
get their values.
Did I mention before that I hate perl? :-)
Both forms are in use in the gnupod code at the moment, I just picked
the first..
Check if they are used for the same purpose. :-)
Here is a new patch with your suggestions and the tunes2pod code. The
diff for XMLhelper.pm looks a bit weird, but all I did was move the
reset code to a new resetxml() sub. The reset is needed because the
playlists are stored in XDAT by doxml() and won't be overwritten by the
playlists from the iTunesDB otherwise.
I'll take a look at a revised patch later ... got to hurry to work.
-henrik
___
Bug-gnupod mailing list
Bug-gnupod@nongnu.org
http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] mktunes.pl creates corrupt iTunesDB ?
Hi Richard,
On Tue, Jun 16, 2009 at 10:05:16PM +0200, Richard van den Berg wrote:
On 6/16/09 12:44 AM, H. Langos wrote:
My first idea now is to
strip the iTunesDB of the stuff that is optional.
Thanks again for the suggestion, that worked really well. I can now see
all my 30415 songs! Whoohoo. :-)
Congratulations! Now please don't go overboard with the patch. :-)
The default behavior for our users should not change. Meaning every possible
mhod should be written. The code and the naming of variables should express
that this is a workaround, not the default. I.e the keepattr would better
be named low_ram_attr or shrink_itunes_db or minimal_attr.
Your mhod skipping code should only be active if that option is set in your
.gnupodrc or given as command line switch.
Did you find out if shrinking the existing attributes (in contrast to
skipping) had any effect? If it did we could keep some counters for mhods
and their cumulative size in mktunes and either print out those stats if we
run in verbose mode (which would have to be added :) ) or print out warnings
if certain limits are reached.
A second patch is needed for tunes2pod
which will read the missing attributes from GNUtunesDB.xml, otherwise
they are gone forever after tunes2pod is run. I'll work on that later.
I wouldn't worry about that, AFAIK tunes2pod is only run once when you start
working with gnupod. Afterwards the flow of information is mostly this:
OTG Playlist
||
vv
GNUtunesDB.xml== iTunesDB
^^
||
Play Counts
You only need to rerun tunes2pod if your GNUtunesDB.xml is lost or if you
played around with iTunes in the meantime ... and we could warn people about
this.
BTW: Does iTunes manage to get your full collection over to your ipod, or
does it also produce an unusable iTunesDB?
Code remarks: I like the passing of optional arguments in a hash. However I
strongly suggest using lower case keys (keep instead of Keep and item instead
of Item.)
- $mktunes-WriteItunesDB;
+ $mktunes-WriteItunesDB(Keep=$opts{'keepattr'});
Shouldn't that be :
$mktunes-WriteItunesDB( {Keep = $opts{'keepattr'}} );
With the additional curly brackets to express that you are defining an
anonymous hash?
Maybe perl quesses right but I am not trusting perl to always do the
right thing. And how would that line look if you add another hashkey?
Would perl put both into one hash or would it pass two separate hashes?
+ my($self, %args) = @_;
+ my $object = $args{Item};
+ my @keep= split(/[ ,]+/, $args{Keep});
my $mhit= ''; # Buffer for the new mhit
my $mhod_chunks = ''; # Buffer for the childs (mhods)
my $mhod_count = 0; # Child counter
@@ -275,6 +277,7 @@
foreach my $key (sort keys(%$object)) {
my $value = $object-{$key};
next unless $value; # Do not write empty values
+ next unless ($#keep0 || grep(/^$key$/,@keep)); # Only
keep specific mhods
my $new_mhod = GNUpod::iTunesDB::mk_mhod({stype=$key,
string=$value});
next unless $new_mhod; # Something went wrong
$mhod_chunks .= $new_mhod;
Instead of @keep, I'd use %keep. and instead of creating it here for
every mhit, I'd create it only once, and pass it along as a hashref.
cheers
-henrik
PS: I've see the following line in the patch. So it seems my empty desc
attributes wouldn't have made it into the iTunesDB anyway:
next unless $value; # Do not write empty values
___
Bug-gnupod mailing list
Bug-gnupod@nongnu.org
http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] Do not stretch artwork
On Tue, Jun 16, 2009 at 10:08:00PM +0200, Richard van den Berg wrote: On 6/15/09 6:01 PM, Christophe Fergeau wrote: The background color is specified in the SysInfoExtended file if you are using/parsing it. Thanks for the suggestion, but gnupod currently doen't parse this file. I think the best thing to do is have an option to select the background color. I think SysInfoExtended is written by gtkpod. I think it was ment as a more readable version of apple's SysInfo file. But newer iPods don't have that SysInfo file anymore. My 3g nano (late 2007) doesn't. See http://www.thismuchiknow.co.uk/?p=15 However, SysInfo is now obsoleted by iTunes 7 / latest firmware update (no device information is actually stored on the mass storage partition anymore). We might add support for it, but currently gnupod is configured via ~/.gnupodrc cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] SoundCheck/ReplayGain
Hi chris, On Tue, Jun 16, 2009 at 11:26:12PM +0200, chris.com wrote: H. Langos wrote: Hi chris, I borrowed an ipod shuffle 3gen (what apple calls iPod shuffle 2nd generation Early 2008) from a collegue but that one seems to be up to date too. All the volume adjustment fields are 00 00 00 Does the revision as shown by udev represent the firmware version? ID_VENDOR=Apple ID_MODEL=iPod ID_REVISION=2.70 If iTunes shows the firmware version somewhere in device information you could compare it to the output of udevinfo --path /sys/block/sda --query env or /sbin/udevadm info --path /sys/block/sda --query env Actually I have a Firmware-131.1.0.3 loaded and I get: ID_VENDOR=Apple ID_MODEL=iPod ID_REVISION=2.70 Ok, so no luck there. Finding itunes 7.4 was really easy but where might I well find an old firmware for a 2nd generation shuffle? Anyone have an idea? Google? Just look for ipod and firmware and the first hit was this: http://www.felixbruns.de/iPod/firmware/ Well, I tried that. I downloaded the iPod_130.1.0.3.ipsw and iPod_131.1.0.3.ipsw firmware from appldnld.apple.com.edgesuite.net. The Firmware part is identical and when connected to iTunes the firmware version shown is 1.0.4 for both of 'm. felixburns has a 133 version, I guess it is more recent. I haven't tried it. Do you want me to load a 130 firmware and send you the iTunesSD? That would be great. Could you find out when that firmware was released? In general I'd like to get the oldest firmware on it that you possibly can. Did any software come with the shuffle? Maybe a it contains a reset utility that contains old firmware? I've found some comment in a forum in late 2006: http://forums.ilounge.com/showthread.php?t=181616 When I updated my 1G shuffle, the computer said the firmware was for some bug fixes and volume control, though I've noticed no difference in the shuffle's operation. If that firmware FIXED the shuffle's behavior to what we see today, and it didn't change from one vaild behavior (the one from 1g shuffle) to another (todays), then we might simply solve the issue by adding new model strings to gnupod and change the behavior of mktunes accordingly. Does apple publish something like a changelog for their firmware updates? cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] mktunes.pl creates corrupt iTunesDB ?
On Wed, Jun 17, 2009 at 12:11:06PM +0200, Richard van den Berg wrote: On Wed, June 17, 2009 10:41, H. Langos wrote: Your mhod skipping code should only be active if that option is set in your .gnupodrc or given as command line switch. That is the case now. If keppattr is not set, @keep is empty and $#keep = -1 and nothing will be filtered. I wouldn't have written it any other way. Ahh, I see ... my brain isn't used to unless statements... I need to translate it to next unless ($#keep0 || grep(/^$key$/,@keep)); #Only keep specific mhods to next if ($#keep=0 !grep(/^$key$/,@keep)); #Only keep specific mhods to understand it right :-) Did you find out if shrinking the existing attributes (in contrast to skipping) had any effect? It has effect on the iTunesDB size for sure, but not as drastically as removing mhods. I can do more testing to see if it has an effect on the iPod accepting the iTunesDB, but I am rather fed up with binary searches at the moment. It takes a lot of time. I'd have to find the critical point in my current configuration and then use the size of the mhods to see if I can push it over or under this point. I don't think we need tu hurry that. It just would be nice to have some numbers when warning users about possible memory issues. You only need to rerun tunes2pod if your GNUtunesDB.xml is lost or if you played around with iTunes in the meantime ... and we could warn people about this. I don't plan on using iTunes, but I could see myself using Floola in combination with gnupod. Wow, Floola looks realy nice. I understand your concern now. This would also be important for people who use gnupod and gtkpod or any other libgpod based applications. So tunes2pod would have to be improved to incorporate new files and playlists and accept changes to existing attributes but to keep those attributes that it already finds in GNUtunesDB.xml. BTW: Does iTunes manage to get your full collection over to your ipod, or does it also produce an unusable iTunesDB? I don't have my collection loaded in iTunes. I was saving that as a last resort. Perhaps I'll give it a try over the weekend, after making sure it can only access my collection read-only. That would be fun and interesting to see which strategy iTunes chooses to save space. Code remarks: I like the passing of optional arguments in a hash. However I strongly suggest using lower case keys (keep instead of Keep and item instead of Item.) I though I was using the gnupod coding convention there. I don't like it either, so I'll fix the other capitalized keys as well. Yes but please keep those changes capitalization changes limited to your new code. I'd liek to put of big cleanup actions until we get the git repository up and runing. I've got things like whitespace cleanup and use warnings; for the old code on my TODO list. Does $value evaluate to false when it is an empty string? I am planning to check which mhods I am now actually filtering. I was quite surprised by the size decrease my patch caused. Perhaps there are some mhods that should be filtered by default. from man perlsyn: Truth and Falsehood The number 0, the strings '0' and '', the empty list (), and undef are all false in a boolean context. All other values are true. Negation of a true value by ! or not returns a special false value. When evaluated as a string it is treated as '', but as a number, it is treated as 0. Cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] mktunes.pl creates corrupt iTunesDB ?
Hi Richard, On Tue, Jun 16, 2009 at 11:46:47AM +0200, Richard van den Berg wrote: On Tue, June 16, 2009 00:44, H. Langos wrote: My first idea now is to strip the iTunesDB of the stuff that is optional. Absolutely. I was thinking the same thing. More along the lines of setting all titles, artists and albums to a single character. But leaving out complete mhods makes a lot more sense. Shortening might not change a lot if memory management is generous and memory alignment of those objects occures on something more than word borders. But you could find out simply by taking the first not-ok state, shorten lots of attributes and try again if the newly genereated iTunesDB works. That would be valuable information regardless of how we solve the problem in the end. Last friday I wrote a patch that will not add them if they are empty. I just need to commit it. Please do, or send me the patch. I'm planning to work on it tonight, and it would be good if my code did not conflict with yours. It's a simple one line patch .. I already commited it. If it works, I'll probably make a switch for it to mktunes.pl. That might be a good idea. My patch only takes out one attribute for one file format. Having a universal switch for big collections could be a good idea. The code there could weed out the not-so-important fields and maybe limit the size of others. Kind of a last-resort switch for big collections. BTW: I've started converting the CVS gnupod repository into a git repository. If Adrian agrees I'd like to give you write access to it. That would be very helpful, thanks. I now keep my custom patches in files, and reapply them when needed. To do that you don't even need write access. You simply clone the upstream repository, create your own local branch and from time to time you pull the changes from origin and either merge the master into your private branch or rebase your private branch onto the HEAD of the master branch. Lets hope Adrian finds time to answer some of my questions so that I can compete the transition to git realy soon. After rcs, sccs, cvs and svn git will be the 5th versioning system I'll have to master. :-) You will love it. I worked with rcs and cvs before but git simply feels better. Working with local branches makes things also much easier. And I actually _enjoy_ working with git. Something that never happend with CVS. Just one example.. When weeding out those empty desc attributes, I inittially commited the patch with a '== ' comparison. Comparing a string numerically with the empty string (Did I mention that I hate weakly typed languages). Then I did some other changes and, commited those. Then I realised that the comparison was wrong, reverted that commit fixed the problem once more. Now my commit history was correct but looked messy. 1. wrong fix 2. some other change 3, revert of 1. 4. correct fix git-rebase to the rescue! You can give it a past commit and it will replay the patches and commits from that past commit to the current state. So I used git-rebase -i to edit the requence of patches, simply took out the initial wrong commit, and the revert and only left 2. and 4. in there. I also could have squashed 1.,3. and 4. into one commit. Or instead of reverting in 3. and commiting a new patch in 4. I could have used rebase when I realized that 1. was wrong. I could have used rebase to replay both commits but pause after applying 1. before commiting it, manually fixed the fix, and then continue that git-rebase. With git you are realy in control of your repository and if you screw up you while manipulating the local history can even reset those changes (before you run garbage collect to remove unaccessible objects from the git repository). cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] Do not stretch artwork
Hi Richard,
Nice patch. I was too lazy to do it myself but I appreciate that patch.
I'll commit it as soon as I can.
On Sun, Jun 14, 2009 at 11:06:02PM +0200, Richard van den Berg wrote:
I might still convert the artwork generation to Image::Magick, but in
the meantime here is a patch to not distort the artwork to a square.
Instead the aspect is preserved, and white bands are added (left + right
or top + bottom) when needed.
...
- open(IM, -|) || exec(convert, -resize,
$mr-{height}x$mr-{width}!, -depth, 8, $file, RGB:-);
+ open(IM, -|) || exec(convert, -resize,
$mr-{height}x$mr-{width},
-background,white,-gravity,center,-extent,$mr-{height}x$mr-{width},
-depth, 8, $file, RGB:-);
Are you sure that white is always the best way? I think the ipod touch
is generally black and thus back might be better there?
Anyway white is default: (from imagemagick.org)
The color is specified using the format described under the -fill option.
The default background color (if none is specified or found in the image)
is white.
cheers
-henrik
___
Bug-gnupod mailing list
Bug-gnupod@nongnu.org
http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] mktunes.pl creates corrupt iTunesDB ?
On Fri, Jun 12, 2009 at 04:33:43PM +0200, Richard van den Berg wrote: On Fri, June 12, 2009 15:21, Heinrich Langos wrote: I'd like to have a chain like this: ok - ok - broken Here is such a chain: http://richard.vdberg.org/gnupod/ok/11181/iTunesDB http://richard.vdberg.org/gnupod/ok/11182/iTunesDB http://richard.vdberg.org/gnupod/ok/11183/iTunesDB http://richard.vdberg.org/gnupod/not_ok/11184/iTunesDB Does this file have anything in its attributes that the files that you added successfully (until #11531) did not have? artwork maybe? Nope. In fact it breaks in the middle of an album. All those songs had been added with the same gnupod_addsong.pl --artwork run. I took a look at that chain (11182-11183-11184) using hexdump, sed and diff and i came pretty much the the same conclusion... Nothing obviously wrong. I wonder if it has anything to do with the IDs that playlist entries get. currently they are just sequentially continued after the last track ID. Thats why you get such a large number of tiny differences in the master playlist even when adding just one track. I don't have much time this weekend but maybe you could check out what happens if you start giving those IDs from the highest value and decrement with each entry. I doubt that this will solve the problem but it probably will help decrease the noise in the diffs. BTW thanks for the hint with vbindiff. I was using some mixture of hexdump, sed (to do linebreaks on mh.. patterns) and diff. Could you try to add the SAME file over and over until you get a non working state? That would make hunt for an overflow in the internal structures even easier. (gnupod_addsong -d allow duplicates). I can do so tonight, but I was rather hoping of finding this bug without having to wipe my iPod. Can't I just create a fake GNUtunesDB.xml with the same file over and over again? I don't have the space left to add another 11000 actual songs to my iPod (unless it's 1 kb or smaller). In my testing so far I've just been manually editing GNUtunesDB.xml and running mktunes.pl to generate a new iTunesDB. Skip that. I was hoping to find some pattern in the added file's characteristic but that will not help. Best way to get there is a binary search. That's exactly what I used last night. :-) 15 iterations for 3 files is the best you can do. Good to kown that we can talk more than just basic patterns. Did you try adding your collection with gtkpod? I assume it will be much faster as it is not written in perl. Nope. I really don't need a GUI and yet another local database to keep track off. I want gnupod! :-) Me too, I was just wondering if their code produced an iTunesDB that wouldn't have the same problem. Then we could look for the differences. cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
[Bug-gnupod] Performance of gnupod on large data sets
On Fri, Jun 12, 2009 at 09:51:18PM +0200, Richard van den Berg wrote: To get some numbers on the performance you could do me a favor and add a single file to the rather full ipod while profiling the perl process. The results are at: With 11600 files http://richard.vdberg.org/gnupod/dprof/run1 With 30415 files http://richard.vdberg.org/gnupod/dprof/run3 After the first run please move the tmon.out file aside and run the same perl -d:DProf /path/to/gnupod_addsong.pl /path/to/file.mp3 line once more. (This time gnupod_addsong should abort before writing the file to your ipod because of the duplicate detection.) The results are at: With 11600 files http://richard.vdberg.org/gnupod/dprof/run2 With 30415 files http://richard.vdberg.org/gnupod/dprof/run4 I did another run with the --artwork switch at http://richard.vdberg.org/gnupod/dprof/run5 I took a glance at the stats and I didn't know that artwork does slow down the process that much. About xescaped.. I'll add a simple check at the start (after taking care of the first couple of XML entities) that will return the string if there are no characters outside the plain ascii range 0x20-0x7F.. thus skipping any of the later regex matches and conversions that only apply to utf8 stuff. cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: Antwort: Re: Antwort: Re: [Bug-gnupod] Support for 4th gen iPod Shuffle
Hi David, On Mon, Jun 01, 2009 at 02:10:46PM +0200, ad...@schueler.homeip.net wrote: H. Langos henrik-gnu...@prak.org wrote on 01.06.2009 11:44:57: On Mon, Jun 01, 2009 at 01:14:20AM +0200, ad...@schueler.homeip.net wrote: H. Langos henrik-gnu...@prak.org wrote on 30.05.2009 23:23:59: You should make it very clear that this is the new iTunsSD format. The older foramt was much simpler. The 4 bytes at offset 0x4 are not total size. they seem to always be 02 00 00 03 independen of size. I wrote some more details in my last posting to the bug-gnupod list. Okay. I updated the http://evil.madrax.de/ipod/itunessd.php script according to your informations. Now it looks a bit more clear. And i moved the iTunesDB script to http://evil.madrax.de/ipod/itunesdb.php I'm adding file uplpoad support this week so everybody may have his iTunesXX file analysed. Hoping that it will be helpful to someone. I have some suggestions: 1. Add a hexdump either for the complete chunk or for the decoded fields. That helps to verify the information we already know (or belief to know) and also shows how wide the decoded field was. Example: [header_length] = 64 (40 00 00 00) 2. Separate bytes in the hexdump by a single space and groups of 8 (or 4) bytes by two spaces and add line break after 16 bytes. Example: [unknown3]= 40 02 00 00 9c 0c 00 00 24 d8 b7 00 00 00 00 00 38 c1 69 00 00 00 00 00 81 00 00 00 3. When decoded output is shown in hex, add the 0x prefix Example: [playlist_header_chunk_offset]= 0xb964 (64 b9 00 00) 4. When allowing users to upload files, create a separate directory for each user session and ask the users to upload the iTunesDB as well as the iTunesSD. This will help to transfer existing knowledge about the iTunesDB to the iTunesSD. (i.e. identifying fields we already know in the iTunesDB) Also ask the user to add as much information as possible. Like: - which version of iTunes was used to create the database, - which iPod device (incl last three letters of the serial number), - what kind of files were added, volume adjustments, and so on. Make it clear that data that users upload will be stored for an unlimited time and that it will be made available to the public. This way you can create a data collections that may help to decode the last unknown fields. Some words of warning because I don't know how much of a security background you already have. When allowing users to send data to your server, don't let them specify the filename. Don't add user input (or data derived from user input) to function calls that could be harmfull. When you output user data always use either htmlspecialchars() or htmlentities(). cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
[ad...@schueler.homeip.net: Re: [Bug-gnupod] Support for 4th gen iPod Shuffle]
Forwarded to the list to be archived... ---BeginMessage--- H. Langos henrik-gnu...@prak.org wrote on 29.05.2009 13:14:11: On Thu, May 28, 2009 at 08:54:58PM +0200, ad...@schueler.homeip.net wrote: Hi Henrik, thank you for spending time on that issue. I did some engeneering on the iTunesDB file ( http://evil.madrax.de/itunesdb.html) and wondered why the file does not Thats a nice link. Do you know how that page was created or could you try to find out? I've done it by my own. It's just a php script which opens the file and reads the mhXX in it and then parses the chunk. But its still incomplete. Until now it reacts on mhbd, mhsd, mhlt, mhit, mhod, mhla and mhia but with fully ignoring any structure. Its just a dump chunk parser. Maybe some day i will do further work on it :D David ---End Message--- ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] Support for 4th gen iPod Shuffle
On Thu, May 28, 2009 at 08:54:58PM +0200, ad...@schueler.homeip.net wrote: Hi Henrik, thank you for spending time on that issue. I did some engeneering on the iTunesDB file ( http://evil.madrax.de/itunesdb.html) and wondered why the file does not Thats a nice link. Do you know how that page was created or could you try to find out? I was thinking about writing an analyzer for the itunesDB format, too. But if somebody else already worked on this I gladly reuse that work. Writing this in perl would be a pain since 90% of the time I would have to spend on fighting perl about variable types. Dynamically typed languages are not suitable for every application... But you know the saying ... if all you have is a hammer, everything looks like a nail. have the structure as mentioned on http://www.ipodlinux.org/wiki/ITunesDB (site seems to be down since yesterday). But i dont have any clue about the different entries. So, if the shuffle reads the SD file why does iTunes populate and store a DB file on the shuffle, too? I've read that iTunes will read back the data from the iTunesDB when you connect your iPod to iTunes again. The old (pre talking shuffle) iTunesSD format is very limited and contains only a small part of the information known to iTunes. So, the iTunesDB is a way for iTunes to store that information on the iPod until you reconnect it. cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] 4th generation iPod Nano
On Thu, May 28, 2009 at 09:13:08PM +0200, Richard van den Berg wrote: On 5/27/09 11:47 PM, Richard van den Berg wrote: I'll post a full patch including the documentation side later. Here is the patch to make the artwork work for the 4th generation iPod Nano. Thank you very much! I tried to commit the patch to CVS but savannah seems to be down at this moment. cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: Antwort: Re: [Bug-gnupod] Support for 4th gen iPod Shuffle
Hi David, I just yesterday realized that the iPod shuffle (at least the older ones) does not read the iTunesDB file but the iTunesSD file. I'll try to take another look at the issue. cheers -henrik On Fri, Apr 03, 2009 at 01:33:48PM +0200, ad...@schueler.homeip.net wrote: H. Langos henrik-gnu...@prak.org wrote on 02.04.2009 11:49:18: Hi David, Sorry for my late answer. But better late than never :-D Did you use gnupod before on a different iPod model? No. I used gtkpod with my old and (since two years defect) nano on a different machine. Could you post the model number? (a letter and 3 digits) I guess you mean the thing that apple calls iPod shuffle (3rd generation)? Yes i meant 3rd generation. Model is A1271 Did gnupod find the fwid? Could you show the output of mktunes? No, it didn't. But its still there in /proc: ~ # cat /proc/bus/usb/devices [...] T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 85 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 2 P: Vendor=05ac ProdID=1302 Rev= 0.01 S: Manufacturer=Apple Inc. S: Product=iPod S: SerialNumber=000A27001Cxx C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms C: #Ifs= 1 Cfg#= 2 Atr=c0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver= E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms (I X'ed the S/N out ... greetings to the german BND ;) Output of mktunes: ~ # mktunes.pl -m /mnt/iPod --fwguid=000A27001Cxx mktunes.pl 0.99.7 (C) Adrian Ulrich GNUtunesDB sync needed... GNUtunesDB synced Loading ArtworkDB...done Parsing XML document... 54 files parsed, assembling iTunesDB... Creating iPod playlists... Hashing database for iPod GUID '0x000a27001cxx' Writing new iTunesShuffle DB Updating Sync-Status You can now umount your iPod. [Files: 54] - May the iPod be with you! and without --fwguid: mktunes.pl 0.99.7 (C) Adrian Ulrich Searching iPod via sysfs node name not found [...message repeating 27 times...] Loading ArtworkDB...done Parsing XML document... 54 files parsed, assembling iTunesDB... Creating iPod playlists... iPod-GUID not detected. You can force the GUID using --fwguid Writing new iTunesShuffle DB Updating Sync-Status You can now umount your iPod. [Files: 54] - May the iPod be with you! Notem that this Serial Number is different from that written on the Package. I tried both, but none worked. iTunes (which version is it?) It's version 8.1.0.52 Do you set a model in your .gnupodrc ? No. I dont have such a file. I hope that infos will help :-) Thanks for you great work on gnupod. If it works with my shuffle sometimes i will code a php frontend for it, because i'm connecting my shuffle to my Linkstaton Pro network hdd and want to fill the music directly over usb. Regards, David ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] SoundCheck/ReplayGain
Hi Chris, On Thu, May 28, 2009 at 10:11:18PM +0200, chris.com wrote: Thanks Henrik for the time spent on this problem H. Langos wrote: Hi chris, On Tue, May 26, 2009 at 11:33:53PM +0200, chris.com wrote: some html... please reconfigure your email client... :-) I'm sorry but I don't see any html and I dont know how to change what. I hope this does it. Yeap. Nothing better than text/plain :-) I didn't look into the files but the are all different at each step. My iTunes is 8.1.1.10 Thank you very much for that data! I didn't look deeply into the iTunesDB because it is not read by the shuffle. (see http://banshee-project.org/~gburt/itunesdb.html chapter about iTunesSD. You'll have to scroll down because the links are broken) As I expected, the only difference between the iTunesSD.gnupod and iTunesSD.iTunes are the volume fields. I took a hexdump -C of them and compared the hexdump outputs: $ diff -U5 iTunesSD.iTunes.hex iTunesSD.gnupod.hex --- iTunesSD.iTunes.hex 2009-05-28 23:04:59.0 +0200 +++ iTunesSD.gnupod.hex 2009-05-28 23:04:59.0 +0200 @@ -1,29 +1,29 @@ 00 00 03 01 08 00 00 00 12 00 00 00 00 00 00 00 || 0010 00 00 00 02 2e 5a a5 01 00 00 00 00 00 00 00 00 |.Z..| -0020 00 00 00 00 00 00 00 00 00 00 ff ff f7 00 00 01 || +0020 00 00 00 00 00 00 00 00 00 00 00 00 64 00 00 01 |d...| 0030 00 02 00 2f 00 69 00 50 00 6f 00 64 00 5f 00 43 |.../.i.P.o.d._.C| 0040 00 6f 00 6e 00 74 00 72 00 6f 00 6c 00 2f 00 4d |.o.n.t.r.o.l./.M| 0050 00 75 00 73 00 69 00 63 00 2f 00 46 00 30 00 37 |.u.s.i.c./.F.0.7| 0060 00 2f 00 67 00 30 00 5f 00 66 00 61 00 6e 00 66 |./.g.0._.f.a.n.f| 0070 00 61 00 72 00 65 00 6d 00 39 00 2e 00 6d 00 70 |.a.r.e.m.9...m.p| 0080 00 33 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |.3..| 0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0230 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 || 0240 00 02 2e 5a a5 01 00 00 00 00 00 00 00 00 00 00 |...Z| -0250 00 00 00 00 00 00 00 00 ff ff fb 00 00 01 00 02 || +0250 00 00 00 00 00 00 00 00 00 00 64 00 00 01 00 02 |..d.| 0260 00 2f 00 69 00 50 00 6f 00 64 00 5f 00 43 00 6f |./.i.P.o.d._.C.o| 0270 00 6e 00 74 00 72 00 6f 00 6c 00 2f 00 4d 00 75 |.n.t.r.o.l./.M.u| 0280 00 73 00 69 00 63 00 2f 00 46 00 31 00 38 00 2f |.s.i.c./.F.1.8./| 0290 00 67 00 30 00 5f 00 66 00 61 00 6e 00 66 00 61 |.g.0._.f.a.n.f.a| 02a0 00 72 00 65 00 30 00 30 00 2e 00 6d 00 70 00 33 |.r.e.0.0...m.p.3| 02b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0460 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 02 || 0470 2e 5a a5 01 00 00 00 00 00 00 00 00 00 00 00 00 |.Z..| -0480 00 00 00 00 00 00 00 00 09 00 00 01 00 02 00 2f |.../| +0480 00 00 00 00 00 00 00 00 64 00 00 01 00 02 00 2f |d../| 0490 00 69 00 50 00 6f 00 64 00 5f 00 43 00 6f 00 6e |.i.P.o.d._.C.o.n| 04a0 00 74 00 72 00 6f 00 6c 00 2f 00 4d 00 75 00 73 |.t.r.o.l./.M.u.s| 04b0 00 69 00 63 00 2f 00 46 00 31 00 32 00 2f 00 67 |.i.c./.F.1.2./.g| 04c0 00 30 00 5f 00 66 00 61 00 6e 00 66 00 61 00 72 |.0._.f.a.n.f.a.r| 04d0 00 65 00 70 00 39 00 2e 00 6d 00 70 00 33 00 00 |.e.p.9...m.p.3..| As you see the gnupod file allways contains 00 00 64 in the volume field while the iTunes generated field contains: ff ff f7 for the -9dB file, ff ff fb for the 0 file (are you sure it is realy 0? soundcheck 3E8 or none at all?), 00 00 09 for the +9dB Unfortunately this is not the format documented in http://banshee-project.org/~gburt/itunesdb.html so we'll have to investigate a little further. Are you sure that the manual volume adjustment in iTunes was +/-0% for all files? It would be great if you could send me some more examples with +6dB and -6dB and maybe +3dB and -3dB. BTW: The differences between iTunesSD.iTunes and iTunesSDbis.iTunes are only in the paths. Everything else is identical. If you want to make sure that the shuffle realy only needs the data in the iTunesSD file, you can wipe the ipod, add those files with gnupod_addsong, and either modify the GNUtunesDB.xml and change the volume attribute, before running mktunes, or you can use a hexeditor on the iTunesSD file after running mktunes. cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] SoundCheck/ReplayGain
Hi chris, On Tue, May 26, 2009 at 11:33:53PM +0200, chris.com wrote: some html... please reconfigure your email client... :-) about CVS: here's the projects main page on savannah: http://savannah.gnu.org/projects/gnupod There you'll find a link to the CVS repository and information on how to use it. I tried the files that you sent with the current cvs version and the version that is packaged for ubuntu 9.04 (some 0.98.7-CVS). Both accept your files and put a soundcheck attribute with the correct value in the xml file. I noticed that your manually generated iTunNORM has a trailing space. Also the laguage code and the comment title should be separated by a null like this: eng0iTunNorm0 0007D ... (see www.id3.org for details), but gnupod recognized it anyway. So the next question is wether the iPod shuffle needs a different format in the itunesdb for the soundcheck attribute. ... spend an hour reading code ... That part of the gnupod code is not maintained very actively and from what I've read in the source there is a special iTunesSD file in a more simple format written for the shuffle and located next to the iTunesDB file. Take a look at iTunesDB.pm and read the comments of the sub routines that deal with the shuffle like mk_itunes_sd_file() and you'll see a lot of unknown fields that go into this file. I suspect that either one of those is the soundcheck field, or more probably that iTunes abuses the volume field to squeeze the soundcheck information into this files. I would be very greatfull if you could make the following experiment: - Backup your iPod and wipe it clear. (I.e remove all songs and playlists) - Take the two files that you sent to me, and maybe add one without any volume adjustment. - Add those three files to an otherwise empty ipod shuffle with gnupod. - Make a copy of the iTunesDB and iTunesSD file. - Verify that they all sound the same. - Connect the ipod to iTunes and let it update the iTunesDB and iTunesSD files. - Verify that the files now have different volumes. - Make a copy of those new iTunesDB and iTunesSD files too. - Send me a copy of both versions for the iTunesDB and iTunesSD along with the information which version of iTunes you used. Thank you very much cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] SoundCheck/ReplayGain
Hi Chris, On Mon, May 25, 2009 at 11:06:45PM +0200, chris.com wrote: I first fetch the RG-tag from the FLAC file and transform it to its SoundCheck equivalent Then I transform the file with flac and lame to a music-only mp3 file (no tags). Next I add (with id3v2) an iTunNORM comment field to the mp3 file and fill it with ten copies of the SoundCheck value (as seen on hydrogenaudio.org) And finally I addsong the file to the iPod. Could you send me a small sample mp3 from this stage in your process? Preferably something short and under creative commons license. (try http://www.freesound.org/ if you need samples) The CVS version will probably do the whole process for you. It will not generate an iTunNORM comment though, but use the replay_track_gain directly to generate the soundcheck attribute. It is however not widely tested yet. mktunes picks up the SoundCheck data correctly; I can see the value in the iTunesDB file, but the iPod doesn't seem to see it, because the volume doesn't get adjusted. Are you sure that the soundcheck value is in the itunesDB? Did you check the iTunesDB with hexdump or did you look at the GNUtunesDB.xml? iTunes as well reads the SoundCheck value I added correctly because when I plug and unplug it with iTunes without changing anything, iTunes recreates the iTunesBD file (with my own SoundCheck value) and now the volume gets adjusted correctly. Maybe iTunes reads your iTunNORM comment and accepts some deviation that gnupod does not? E.g. gunpod insists on finding a space in front of the first hex number group in the iTunNORM comment. 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 24, 2009 at 10:22:17PM +0200, Richard van den Berg wrote: On 5/24/09 2:33 AM, H. Langos wrote: One thing to keep in mind is that the --min-vol-adj and --max-vol-adj now only affect the RVA/RVAD tag information instead of something extracted from RVA2 tags. (I need to update the help text about that.) Since RVA2 now changes the SoundCheck field in the iTunesDB it can still be ignored by disabling Sound Check on the iPod. Ok. I didn't know that. I'll leave it as it is then and the final thing I'll do about this topic will be changing the output format for the soundcheck field. I'll make gnupod_find report the adjustment in dB instead of the raw integer value. This should also help spotting bugs in that area. cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] Append artist to title in iTunesDB
Hi Richard,
There are (hopefully) not that many braindead devices out there. At least
they are probably not all braindead in the same way. :-)
Currently I think it should not be in the code base.
This may change if more people report the same problem.
cheers
-henrik
On Thu, May 21, 2009 at 09:13:54PM +0200, Richard van den Berg wrote:
Since my car iPod adapter is brain dead and only displays the title of
songs, I've patched gnupod to append the artist to the title in the
iTunesDB. It's stripped again by tunes2pod.pl so the GNUtunesDB.xml
stays clean.
If this is a feature that could be useful to others, let me know and
I'll make it optional using a switch to mktunes.pl and tunes2pod.pl
Cheers,
Richard
? .gnupod_version
? Makefile
? autom4te.cache
? config.log
? config.status
? configure
Index: src/ext/Mktunes.pm
===
RCS file: /sources/gnupod/gnupod/src/ext/Mktunes.pm,v
retrieving revision 1.6
diff -u -r1.6 Mktunes.pm
--- src/ext/Mktunes.pm6 Oct 2007 07:26:52 - 1.6
+++ src/ext/Mktunes.pm21 May 2009 19:09:50 -
@@ -275,7 +275,7 @@
foreach my $key (sort keys(%$object)) {
my $value = $object-{$key};
next unless $value; # Do not write empty values
- my $new_mhod = GNUpod::iTunesDB::mk_mhod({stype=$key,
string=$value});
+ my $new_mhod = GNUpod::iTunesDB::mk_mhod({stype=$key,
string=($key eq title?$value. | .$object-{artist}:$value)});
next unless $new_mhod; # Something went wrong
$mhod_chunks .= $new_mhod;
$mhod_count++;
Index: src/ext/iTunesDB.pm
===
RCS file: /sources/gnupod/gnupod/src/ext/iTunesDB.pm,v
retrieving revision 1.113
diff -u -r1.113 iTunesDB.pm
--- src/ext/iTunesDB.pm 12 May 2009 10:36:52 - 1.113
+++ src/ext/iTunesDB.pm 21 May 2009 19:09:51 -
@@ -1208,7 +1208,12 @@
$r{string_size} = get_int($seek+28,4,$fd);
my $tmpstring =
get_string($seek+($r{total_size}-$r{string_size}), $r{string_size}, $fd);
$tmpstring = Unicode::String::byteswap2($tmpstring);
+ if($r{type} == 1) {
+# Title mhod, strip added artist
+$r{string} = shift(@{[split(/ \|
/,Unicode::String::utf16($tmpstring)-utf8)]});
+ } else {
$r{string} = Unicode::String::utf16($tmpstring)-utf8;
+ }
}
return \%r;
}
___
Bug-gnupod mailing list
Bug-gnupod@nongnu.org
http://lists.nongnu.org/mailman/listinfo/bug-gnupod
___
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 Sat, May 09, 2009 at 08:34:57PM +0200, H. Langos wrote: Yes. We would leave volume alone and go for soundcheck instead. We would stop using that crude one byte and start using that 32bit dBm value. At least thats what it is supposed to encode. I just greped through my mp3s and I have only found positive values ranging from 21 to 4219 (= 4.219 dB ) Sorry. This conversion was total BS. soundcheck 4219 = -6.252 dB soundcheck 21 = +16.7 dB I would suggest that you take some stuff that is too loud i.e. louder than the magic 89dB, feed it to iTunes and see how iTunes encodes negative adjustments. I shouldn't write email after spending the whole day sitting in the sun.. ;-) cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] Re: problem with gnupod
Hi Adam, As you already figured out, the trouble was caused by gnupod trying to find the devices serial number (aka fwid). The problem is that gnupod used a rather crude way to look for the device in /sys/block and ubuntu has recently made some big changes there. The problem you describe has been reported before: http://lists.gnu.org/archive/html/bug-gnupod/2009-04/msg3.html It would be great if you could check out the current CVS version of gnupod to see if it works any better: sudo su - apt-get remove gnupod-tools apt-get -y install cvs apt-get -y install autoconf cvs -z3 -d:pserver:anonym...@cvs.savannah.gnu.org:/sources/gnupod co gnupod cd gnupod autoconf ./configure make intall cheers -henrik On Sun, May 10, 2009 at 02:26:41PM -0700, Adam Petcher wrote: 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 adampetc...@yahoo.com wrote: From: Adam Petcher adampetc...@yahoo.com 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 mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] Patch to support ReplayGain / mp3gain
Hi Richard,
On Sun, May 10, 2009 at 10:53:42PM +0200, H. Langos wrote:
On Sun, May 10, 2009 at 10:35:57AM +0200, Richard van den Berg wrote:
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 made a couple of changes before commiting your patches.
First of all I changes the option --no-ape to --no-ape-tag. .ape is also
an audio file extention and naming the option only --no-ape could suggest
that it is about the file format instead of the tag.
NOT: This is only a change in the user interface. Internally the hash key is
still called noAPE.
Then I changes the regex in _parse_ReplayGain as already discussed:
|return undef unless defined($gain);
|if($gain =~ /(.*?)\s*dB$/) {
I also changed a regex further down:
|return undef unless ($gain =~ /^\s*-?\d+(\.\d+)?\s*$/);
This is a little more strict as it will not allow stuff like -4. or
15.. I.e. if there is a dot, it insists on finding at least one digit
after the dot.
I tested it with an mp3 that contains a TXXX tag with replay_gain_track
and replay_gain_album where converted to soundcheck attribute as expected.
I'll add the version check in autoconf.ac for MP3::Info before I commit
the change though.
cheers
-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: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
On Fri, May 08, 2009 at 12:54:33PM +0200, Richard van den Berg wrote: On 5/8/09 11:51 AM, H. Langos wrote: Smart playlists can have a desc attribute? I didn't know that. Does tunes2pod retain it? If so, could you send me the relevant lines from your GNUtunesDB.xml ? I will probably not do anything with it but I'm curious. I created it with iTunes, and it filled the playlists with the songs currently on the iPod. From GNUtunesDB.xml: smartplaylist checkrule=spl limititem=song limitsort=artist limitval=25 liveupdate=1 matchany=1 moselected= name=Veere plid=292683058 spl action=CONTAINS field=DESCRIPTION string=/somedir/ / splcont id=2771 / [snip] splcont id=2769 / /smartplaylist smartplaylist checkrule=spl limititem=song limitsort=random limitval=25 liveupdate=1 matchany=1 moselected= name=Random plid=3323171954 spl action=!eq field=playlist string=292683058:292683058 / splcont id=2693 / [snip] splcont id=2735 / /smartplaylist Ah, I see. You are filtering for the content of the description field. I thought the _playlist itself_ had a description and I was wondering how/where the ipod would have shown it. But since they are liveupdate smart playlists, after adding more mp3s using gnupod (not from /somedir/) and without running iTunes, they did show up in the playlist named Random. Which is exactly what I want. Could be. Could you test if the desc attribute in combination with the lyrics_flag attribute result in displayed lyrics? Apart from the desc attribute i wouldn't know where the lyrics could be stored. I forced the lyrics_flag to 1 in mk_mhit() but I still don't see the description. Pressing the center button I still cycle through: volume - position - artwork - rating strange. which generation ipod is that? http://support.apple.com/kb/HT1353 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 Fri, May 08, 2009 at 04:16:45PM +0200, Richard van den Berg wrote: On 5/8/09 2:26 PM, H. Langos wrote: Yeap. And if mp3gain can't be changed to do write RVA2 tags by itself, maybe there is a way to make mp3gain only do the analysis and pass its result to a programm that can write those RVA2 tags? That would be possible using: $ mp3gain -o -q -s s foo.mp3 FileMP3 gaindB gainMax AmplitudeMax global_gainMin global_gain foo.mp3-7-10.5038780.534185255145 Album-7-10.5038780.534185255145 Well, then thats the way to go. Just write some awk or perl wrapper around it, push those values into your favorite tagger and there you go. Do you know if the author of mp3gain is still active? reachable? alife? I have no clue.. in the thread from 2004 they mention he was unresponsive. So how do we get mp3gain's analysis results into RVA2 / XRVA tags? By changing the mp3gain C code. It's open source after all. I just don't have the stomach or time for it at the moment. Perhaps using the tagging code from normalize will make it easier. However, there could be a good reason not to attempt it. From http://jwz.livejournal.com/370342.html?thread=4232358#t4232358 Anway, whats not clear to me is if the RVA2 value could be used with ReplayGain. Both ReplayGain and RVA2 are applied as a constant value across the complete track, but I'm not sure the units are the same as the RVA2 tag. Well, the gain is given in dB relative to a reference level that most times is 83dB (But sometimes might be 89dB. The nasty details are here: http://www.mars.org/mailman/public/mad-dev/2004-February/000993.html ) I assume that mp3gain uses 83dB. But it wouldn't hurt to check. The units are in both cases dB. The encoding is different. mp3gain writes some prosa while the RVA2/XRVA tags are more terse encoding, but they both deal with relative volume changes in dB. Are you sure about the non desctructivnes of mp3gain? You can run mp3gain in several modes, either (often reversible) changing the volume of the file or just tagging it. I use it only for tagging. From the Debian man page: mp3gain actually changes your file’s gain only when you use one of the options -r, -a, -g, or -l. If none of these options is given, only a tag denoting the recommended gain change is written to the file. Thats good to know! Thank you! And thank you very much for testing mp3gain's undo feature. 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
Sorry about that. It's fixed now.
cheers
-henrik
On Sat, May 09, 2009 at 01:04:15PM +0200, Richard van den Berg wrote:
On 5/8/09 2:26 PM, H. Langos wrote:
BTW: I just added XRVA support as it is a too simple to let it pass.
Always test before commit. ;-)
Global symbol %hs requires explicit package name at
/opt/local/lib/perl5/5.8.9/darwin-2level/GNUpod/FileMagic.pm line 542.
$hs{RVA2} = $hs-{XRVA} if (!defined($hs-{RVA2}) defined($hs-{XRVA}));
should be
$hs-{RVA2} = $hs-{XRVA} if (!defined($hs-{RVA2})
defined($hs-{XRVA}));
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
Hi Frank, On Fri, May 08, 2009 at 12:14:53PM +0200, Frank Blendinger wrote: On Thu 2009-05-07 21:16, Richard van den Berg rich...@vdberg.org proclaimed: On 5/7/09 5:06 PM, H. Langos wrote: What's important is the fact that there seems to be a standard that defines how volume adjustment data can be stored in id3 tags. Nice research. RVA2 is definitely the standard to use, and gnupod already has support for it. The problem is that there is not a lot of software that writes RVA2 tags. (The only ones I know about are iTunes and normalize). mp3gain should really be changed to write RVA2 tags instead of APE ones. You might want to take a look at this python script: http://mpd.wikia.com/wiki/Hack:ape2id3.py It will read the ReplayGain settings from APE tags and add it to ID3v2 tags. It has worked without any problems for me so far. Oh, this is a new one .. it takes the prose that mp3gain and vorbisgain generate and stores it in a prose id3 tag ... So to sum this up, we could have to deal with: * APE tags * RVA2 in ID3v2.4 or XRV/XRVA in ID3v2.3 or RGAD in ID3v2.3 * iTunNORM as Comment in either ID3v2.3 or v2.4 Did I miss anything? You missed the id3v2.3 RVAD tags. The definition in the standard is IMHO a horrible read. Little wonder the apple guys used it in a way that certainly was not intended by the standard's authors... https://savannah.nongnu.org/support/?105294 The intended use stays unclear. But maybe my hifi karma is not good enough to grasp it ;-) All of those could potential be present at once in a file. There can only be either an ID3v2.3 or an ID3v.4 as far as I can tell. But there can always be that iTunNORM comment in addition to the RG tags, and also additional APE tags. I have actually seen files in the wild that have all of this present. [1] So how will gnupod handle this? I suppose the iPod will just use iTunNORM and ignore anything else. Will gnupod use a present iTunNORM comment or will it always create one from ID3v2/APE information? Currently gnupod writes the soundcheck attribute it gets from iTunNorm comments as well as the volume attribute computed from the RVA2/XRVA tag. The volume attribute however is limited in its scale. it can only go from -100% to +100%. The lower bound is ok as it represents silence, but the upper bound is BS as it only allows gains of 6dB. So I guess we might want to abandon that in favor of manipulating the soundcheck attribute: http://www.id3.org/iTunes_Normalization_settings As I see it now. I am wasting a lot of time on this. I'll think about it but I guess I will not put too much work into it myself. 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 Sat, May 09, 2009 at 12:13:01PM +0200, Richard van den Berg wrote:
On 5/9/09 9:14 AM, Frank Blendinger wrote:
I'll talk to the mpd developers to see if they are willing to support
RVA2/RGAD and/or APE tags.
I used mpd before switching to a Squeezebox. IIRC it is written in perl.
If they are using MP3::Info adding APE support is easy; just add an
extra option to the get_mp3tag() call.
mpd is written in C.
It already has APE tag support but I don't know if that support is
limited to certain file formats.
Do I understand you correctly that this could lead to have two gain
values added on top of each other? I don't think you'd want that...
...
I think this would destroy the whole have all songs at the same average
volume level concept, when you apply something else on top of the
ReplayGain data.
I agree, and I think Apple implemented it this way because Sound Check
uses a crappy algorithm. When you use Replay Gain there is really no
need for manual adjustments or combining the values.
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.
At least according to the mpd guys, those TXXX tags are quite common, so
it might help some people if those are supported in gnupod. Personally,
I'm going to keep the APE tags on my files, so I don't care that much.
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?
cheers
-henrik
___
Bug-gnupod mailing list
Bug-gnupod@nongnu.org
http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] DESC field in iTunesDB
On Thu, May 07, 2009 at 06:23:01PM +0200, Richard van den Berg wrote: On 5/7/09 1:50 PM, H. Langos wrote: I wasn't aware of a limitation to 40 characters. This seems a rather arbitrary limit imposed on the user by itunes. It doesn't even resemble the original id3v1 comment tag limit as that was 30 characters. ( http://www.id3.org/ID3v1 ) My bad. I took the width value of %FILEATTRDEF in iTunesDB.pm to mean the width of the field in the iTunesDB. It turns out it is only used as display width in FindHelper.pm. The mk_mhod() / mk_mhit() functions that actually convert the fields to iTunesDB format do not seem to impose any size limit. I probably should move that %FILEATTRDEF stuff over to FindHelper.pm . Initially I thought I could combine the iTunesDB format information that is in the code of iTunesDB.pm with the information regarding its presentations that I added in %FILEATTRDEF. But I don't have the time to dig into the itunesdb format deep enough to combine those. Meanwhile code that used to be in gnupod_find has been generalized and moved into the new FindHelper.pm and that is now probably be better place for %FILEATTRDEF. I haven't been able to read the desc field I set on my mp3s using gnupod_addsong.pl + mktunes.pl either on my 5G iPod or using the iTunes GUI. Seems like that only works for audio podcasts. I can use it in smart playlists though. Smart playlists can have a desc attribute? I didn't know that. Does tunes2pod retain it? If so, could you send me the relevant lines from your GNUtunesDB.xml ? I will probably not do anything with it but I'm curious. Googling shows that my iPod should be able to display lyrics, but I guess the lyrics_flag needs to be set first. Gnupod doesn't seem to do that for mp3s (which I guess is a bug). Could be. Could you test if the desc attribute in combination with the lyrics_flag attribute result in displayed lyrics? Apart from the desc attribute i wouldn't know where the lyrics could be stored. If you need to get the information that currently is encoded in the file's path into the file itself I would recommend using a comment tag. I thought about that, and mass tagging my collection is not a big deal, but I'll have to redo it every time I add something, or move files from one directory to another. Hacking gnupod is much easier, and I won't have to change my habits. :-) I'll see if keeping a customized version of gnupod is better than changing the way I tag/select my mp3 collection. Maybe you can minimize the change by simply add the information that you need to the __merge_strings call. That way you can use the desc attribute both ways. (unless your mp3 collection has a lot of garbage in the comment tags. mine has.) 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
Hi Richard,
On Fri, Apr 17, 2009 at 11:02:22PM +0200, Richard van den Berg wrote:
I'm successfully using gnupod on my iPod video 30GB. Thanks to everyone
who contributed to this great tool!
I have all my mp3s tagged for ReplayGain volume leveling using mp3gain.
This tool adds ReplayGain information using APE tags. Making gnupod read
these tags and apply them as SoundCheck values was surprisingly easy.
Boy, I love open source software. :-)
Thank you very much for your feedback and your contribution.
There might be a side effect if you have APE tags that also contain
(wrong) title and artist information. I don't have such files to test
with, but implementing a --disable-ape switch might be a good idea. Let
me know if you need me to provide a patch for that as well.
This would indeed be very helpful.
Until now gnupod didn't pay any attention to APE tags in mp3 files.
Therefore I am reluctant to make the new behavior a default and only
have a noAPE option.
Usually it would be a clear case against the new default behaviour.
On the other hand a --noAPE or --noAPEtag would fit in better with the
current set of options. Also the next release of gnupod will probably
contain some new tools and we might get away with changing some aspects of
the existing tools in the dust cloud generated by the rush on those glorious
new tools (I wrote them, so I can be ironic about them without stepping on
anybody's toes :-) )
This patch is against the current CVS version.
Thanks! That makes things easier. I personally use git but I keep it in sync
with the official CVS. Could you use unified patch format (diff -u) ?
I find that more readable as the changes are closer together in the
diff output.
It will prefer ReplayGain
APE/id3v2 tags over iTunNORM id3v2 comments. The ReplayGain algorithm is
far superior over the peak based SoundCheck algorithm iTunes implements,
so it wouldn't make sense the other way around.
But in the end they both produce one integer number that is applied as a
simple scaling factor, right? So the superiority of the the ReplayGain
algorithm is something that depends on the software used to produces those
tags. Therefore I would like to give the user some control over this. One
(crude) way of doing it, is the --noAPEtag option.
I think it should be noAPEtag instead of noAPE as the program that takes
this option (from the users perspective) is gnupod_addsong and noAPE might
suggest that APE format files are to be excluded.
Here are some suggestions for your patch in detail:
- Rename convertReplayGainToSoundCheck to _parse_ReplayGain.
- Make the sub first check if the argument is undef. That saves you the
'if($hs-{REPLAYGAIN_TRACK_GAIN} ne )' line which probably is not what you
want to check for in the first place.
- Make the sub return undef if the argument was undef or if the argument could
not be parsed.
- Change the call to something like this: (I'm improvising here so don't
use it as it is...)
$soundcheck = ( _parse_ReplayGain($hs-{REPLAYGAIN_TRACK_GAIN}) ||
_parse_iTunNORM($hs-{COMM} || $hs-{COM} || $h-{COMMENT}) )
This will probably fail if _parse_ReplayGain() ever returns a valid value
of 0. So you might have to write a more elaborate version like this:
$soundcheck = _parse_iTunNORM($hs-{COMM} || $hs-{COM} || $h-{COMMENT})
unless defined ($soundcheck = _parse_ReplayGain($hs-{REPLAYGAIN_TRACK_GAIN})) ;
But taking a second look at that sub, it probably never does produce 0. So
the first and easier to understand version should be ok.
- Some words of documentation in pod format would be great. (Just
cut'n'paste'n'edit and try perldoc src/ext/FileMagic.pm to see the result)
- I like the round() sub. Elegant usage of = operator. (I never got the
hang of it). However, a sub that is only called once, could probably be
left out. If you want to maintain readability, you might put the round
operation in a separate asignment. Even if you put it on one line, the
usage of $number in the = operation can be replaced by -$gain or
$gain, as it only depends on the sign, right?
cheers
-henrik
PS: Please don't take the number of suggestions as an indication of poor
quality. Quite the opposite is true. You might well know more perl than I do.
If the patch was poor I would have probably just fixed those things myself.
Instead I hope you take it as motivation to continue work on gnupod. We could
do with some fresh blood. :-)
___
Bug-gnupod mailing list
Bug-gnupod@nongnu.org
http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] Questions about play counts
Hi Frank, My knowledge of the iPod is limited to say the least but I'll try to answer anyway. I can be completely wrong or even completely mad ... hey, it's the internet. dont trust anybody ;-) There used to be last-fm support builtin in gnupod. I don't know why it was removed. Happend before I started using gnupod and since I don't like the idea of telling the whole world which music I listen to, I didn't care when I found out. On Fri, Apr 10, 2009 at 04:39:52PM +0200, Frank Blendinger wrote: Hi, I am using GNUpod with my iPod nano (3G) and I am very happy with it. There is just one thing I am still missing (and currently trying to get done): submit the songs played on the iPod to last.fm. I use the same iPod. 4g nano is nice but i know people who complain about the short battery life. my guess is, they don't use the hold switch and the acceleration sensors kick in all the time when they walk and the ipod shakes in their pocket... backlight goes up ... battery goes down... I have tried to use qtscrob[1], which tries to the ``iTunesDB'' and ``Play Count'' files in iPod_Control/iTunes. However, it fails, as I don't have such a file on my iPod. I have the Play Count file in iPod_Control/iTunes but as soon as you start a gnupod_search or any other gnupod command, gnupod detects that the iPod has done something that is not yet included in the GNUtunesDB.xml You will see: On-The-Go data sync needed... On-The-Go data synced This means that gnupod reads the files, incorporated that information in GNUtunesDB.xml, and deletes those files. At this point your GNUtunesDB.xml is up to date and the playcount, played_flag and lastplay should be correct. (more or less correct. I messed with the played_flag to also be changed to 1 for podcasts that you didn't listen to completely.) I have seen that the GNUtunesDB.xml also has some information that could possibly be used, ``playcount'', ``played_flag'' and ``lastplay''. Now I am not sure where I should go from there. Should I try to get that missing ``Play Count'' file on my iPod? Or I better try to parse the GNUtunesDB.xml? I guess you can try both ways. Use qtscrob _before_ running gnupod, or parse GNUtunesDB.xml afterwards. BTW: the CVS version of gnupod contains gnupod_find.pl with that tool you can access any attribute that you see in GNUtunesDB.xml E.g. gnupod_find.pl --sort lastplay --view lastplay,default I just tried that and currently lastplay is reported back in MACTIME ( seconds since 1.1.1900) I'll change that to human readable output tonight. Some clarifications about how the play count data is handled would be very helpful. I assume that the iPod device itself increases a play counter in the iTunesDB file and also sets a timestamp there. No. AFAIK the iPod only reads the iTunesDB. It never writes to it. Whatever the iPod writes, is written to separate files and later merged back into the iTunesDB either by iTunes or gnupod's mktunes. What about that ``Play Count'' file? Where should that come from? iTunes maybe? And how and when does the information get from the iTunesDB to the GNUtunesDB.xml - when mktunes is called? mktunes.pl only _writes_ a new iTunedDB file. tunes2pod.pl _reads_ iTunedDB and creates a GNUtunesDB.xml (you only use it once when you already have data on your ipod and want to start managing it with gnupod.) gnupod_otgsync.pl is the one that reads the Play Count file an updates the GNUtunesDB.xml. It is called automatically by e.g. gnupod_search or pretty much any other gnupod programm. How would I reset the play counts after I have submitted them? why should you? why not keep the old value and only transmit a delta? -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] Problem over 32946 entries in GNUtunesDB.xml
Hi Pierre-Marie, On Mon, Nov 24, 2008 at 12:28:06AM +0100, Pierre-Marie Gandoin wrote: Hello and thank you very much for your software ! I use a 6G Classic iPod (160 GB) with Gnupod since about one year without any problem. But today, updating my content from 25728 to 37986 songs, after a reboot, the iPod didn't work any longer. The browsing was impossible and it announced 32946 songs. However, the mktunes output seemed correct : ... 37986 files parsed, assembling iTunesDB ... I don't have any hands on experience with such a large database. I tried gnupod_add and _search with about 24000 files but only as a dry run into a directory. I use a Nano 3G (8GB) so I can't actually try anything close to your collection's size on the device. Now, after truncating the GNUtunesDB.xml file below 32946 entries, the iPod worked again as usual. Is there some kind of limit over the song numbers (we are close to 2^15) ? If it was a 2^15 problem it would have struck at 32768, so going below 32946 you would still have almost 200 files too many. Could you post the complete output of mktunes? (Must I subscribe to the mailing list to read your answer ? I don't find any clue to do this on the gnupod web page.) You don't need to subscribe if I put you on Cc: . But if you like to, you can subscribe at http://lists.nongnu.org/mailman/listinfo/bug-gnupod The list is very low volume. Also, I would like to know if it is possible to have several entries of the GNUtunesDB.xml pointing on the same file (useful in the case of a multi-artist song, to access it from each artist). If not, that could be the cause of my problem, since this is the first time I do this. This could indeed be a problem for the iPod software. I don't know the binary format of the iTunesDB but messing with references like that could cause problems for the database parser on the ipod. I suggest you try to add those files without adding cross references first. Cheers -henrik BTW: Which version of gnupod are you using? ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
[Bug-gnupod] Suggested re-design of gnupod_search.pl
Hi gnupod users, Adrian has allowed me to make some changes and (hopefully) improvements to gnupod. The changes are in cvs and a 0.99.8 should be released soon. It will probably become 1.0 as soon as the most obvious bugs are fixed :-) For the next version after 1.0 I've already implemented some features and I'd like to do some serious rewriting of existing tools. I've taken a look at gnupod_search.pl and eventhough it is small and nicely written I'd suggest a modular rewrite that better separates the different tasks that it has come to do. gnupod_search will only do the search and show the results. gnupod_modify will modify tags. gnupod_remove will delete songs from your ipod. To keep it compatible I'd leave the existing command line switches for gnupod_search as they are, but to give full access to all song attributes as stored in the XML structure I'd add search show sort options that take full attribute names. So you could call gnupod_search --search artist=Pink Floyd,album=The Wall --sort cdnum,songnum --show songnum,title to get the track numbers and titles of that 2 CD album sorted by CD and track number. To improve user experience gnupod_search needs to be more aware of what type of data it handles. It already knows how much space an attribute needs for the output (thats why the id column is much smaller than the artist column), and it knows what to write into the column header. But it also needs to know if an attribute is numeric or a string or a date. This will make it much easier to refine searches. --search will understand some modifiers for people not familiar with regular expressions and some extentions that can't be done with regular expressions at all. So --search artist==Pink would find just Pink and not Pink Floyd, and --search year=2005 would find songs made before 2005, and --search addtime=2008-07-15 would find songs added to my ipod before July 15th, and --search addtime=yesterday would find songs added in the last 24h, and --search releasedate=last week will find podcast entries that are older than a week. Sounds fun doesn't it? --sort will understand modifiers like + and - so that --sort -title will reverse the sorting by song title. gnupod_remove will work exactly as the new gnupod_search will but will delete the songs it finds. gnupod_modify will take the same new options as gnupod_search but will also have a --set option that works pretty much the same way as the --search option does. So --set artist=Foo Fighters,year=2002 will do what you expect it to do. So, what do you guys think? Any suggestions? Things I have overlooked? Things that you miss in gnupod_search? Is the equals sign in --search year=2005 suggesting to strongly that the year 2005 is included? Should = be replaced by : ? Should = be treated like == and =~ be the modifier for regex match? Or how about having one character only? artist=Pink exact string match artist~Pink regex match artistPink alphabetically larger artistPink alphabetically smaller Or would that be too dangerous with all the wannebe smart shells out there that would easily interpret it as redirection of stdin/stdou? (Remember I want to make gnupod more pleasant to the less experienced user.) Should gnupod_search be left alone and gnupod_find be the name of the new modular search tool? Should gnupod_remove and gnupod_modify be interactive by default and have a --force switch for non-interactive mode? Tell me what you think! I make no promises whatsoever that in the end I will not simply decide what I think is best, but hey .. if you run linux you are used to benign despotism ;-) cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] Encoding of non-ascii characters in GNUtunesDB.xml
Patch of the patch ... performance is better but still could be improved
i guess.
Instead of making 4 utf8 conversions and 3 substring operations on each
character we are down to one ord() and one substr() per character. Still
bad but way better than before.
-henrik
PS: Anybody interested in getting complete usable files instead of
patches?
On Mon, Apr 14, 2008 at 08:12:30PM +0200, H. Langos wrote:
Ok, here's the patch ...
Took longer than I thought because UTF8 in perl is a major pain.
cheers
-henrik
PS: The line $xutf =~ tr/\000-\037//d; is not without problems. It
will reduce all control characters to nothing including TAB, LF,
and CR eventhough they are valid XML characters.
Could somebody check out how iTunes handles those? Does it also remove
those characters or does it convert them into #9; and so on?
On Mon, Apr 14, 2008 at 02:14:18PM +0200, H. Langos wrote:
Hi there,
I wonder If anybody else has the ocassional problem with editing her/his
GNUtunesDB.xml.
Since it is XML and the encoding is UTF-8 you don't have any problem as
long as your system is completely UTF-8 compliant. I however have a
mixed iso-8859-1 iso-8859-15 and UTF-8 mess and some of the editors
that I like to use are not very smart about handling the character
encoding.
It would be very easy to convert everything outsite the ascii range to
the XML escaped version. So say, instead of some garbage you'd see
#347; where a Latin Small Letter s with Acute is.
Pro: GNUtunesDB.xml becomes a pure ascii file. No more editor/viewer
issues.
Contra: The GNUtunesDB.xml becomes slightly bigger and for people with a
clean UTF-8 toolchain it becomes a little less readable. (Note: You can
still edit the file and insert native UTF-8 as you please.)
Any thoughts?
cheers
-henrik
___
Bug-gnupod mailing list
Bug-gnupod@nongnu.org
http://lists.nongnu.org/mailman/listinfo/bug-gnupod
commit 5ce6a9e9173dce95287ff4b15deda67b569dd365
Author: Heinrich Langos [EMAIL PROTECTED]
Date: Mon Apr 14 19:49:54 2008 +0200
Changed encoding of unicode characters outside of ascii range to XML
notation.
This change will make your GNUtunesDB.xml into a pure ascii file. Making
it
easier to view and manipulate on non-utf8 capable systems.
Note: xescaped() is not only called for attribute values but also for
element names and attribute names. So if sombody comes up with non-ascii
element names or attribute names we would have to treat those differently.
diff --git a/src/ext/XMLhelper.pm b/src/ext/XMLhelper.pm
index 5eaeb48..2a230a3 100755
--- a/src/ext/XMLhelper.pm
+++ b/src/ext/XMLhelper.pm
@@ -124,8 +124,15 @@ sub xescaped {
my $xutf = Unicode::String::utf8($ret)-utf8;
#Remove 0x00 - 0x1f chars (we don't need them)
$xutf =~ tr/\000-\037//d;
-
- return $xutf;
+ my $out = Unicode::String::utf8()-utf8;
+ for (my $i = 0 ; $i Unicode::String::utf8($xutf)-length ; $i++) {
+ if (Unicode::String::utf8($xutf)-substr($i,1)-ord 127) {
+ $out .= '#' .
Unicode::String::utf8($xutf)-substr($i,1)-ord . ';';
+ } else {
+ $out .= Unicode::String::utf8($xutf)-substr($i,1) ;
+ }
+ }
+ return $out;
}
___
Bug-gnupod mailing list
Bug-gnupod@nongnu.org
http://lists.nongnu.org/mailman/listinfo/bug-gnupod
commit 1ace27099b20dfc5bb08fe764b30c9c2276729a9
Author: Heinrich Langos [EMAIL PROTECTED]
Date: Tue Apr 15 01:15:21 2008 +0200
Improved performance of utf8 to ascii encoding.
diff --git a/src/ext/XMLhelper.pm b/src/ext/XMLhelper.pm
index 2a230a3..b1ab134 100755
--- a/src/ext/XMLhelper.pm
+++ b/src/ext/XMLhelper.pm
@@ -124,12 +124,14 @@ sub xescaped {
my $xutf = Unicode::String::utf8($ret)-utf8;
#Remove 0x00 - 0x1f chars (we don't need them)
$xutf =~ tr/\000-\037//d;
- my $out = Unicode::String::utf8()-utf8;
- for (my $i = 0 ; $i Unicode::String::utf8($xutf)-length ; $i++) {
- if (Unicode::String::utf8($xutf)-substr($i,1)-ord 127) {
- $out .= '#' . Unicode::String::utf8($xutf)-substr($i,1)-ord . ';';
+ my $u16 = Unicode::String::utf8($xutf);
+ my $out = ; #pure ascii
+ for (my $i = 0 ; $i Unicode::String::length($u16); $i++) {
+ my $ccode = Unicode::String::substr($u16,$i,1)-ord;
+ if ($ccode 127) {
+ $out .= '#' . $ccode . ';';
} else {
- $out .= Unicode::String::utf8($xutf)-substr($i,1) ;
+ $out .= chr($ccode) ;
}
}
return $out;
___
Bug-gnupod mailing list
Bug-gnupod@nongnu.org
http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] Re: playcount not updating.
Hi Paul, I've seen pretty much the same behavior. Tracks that the ipod doesn't mark as new anymore are reset to new by mktunes. Did you try to run gnupod_search.pl before gnupod_addsong.pl? I think that addsong doesn't call otgsync (which extracts on-the-go data from the itunes db and adds it to GNUtunesDB.xml) while search does. Does it make a difference if you let the ipod complete the playback of a podcast track or if you skip the rest of the track ? cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
