[Bug-gnupod] Configure as_echo fix
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. Cheers, Richard ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
[Bug-gnupod] Text::CharWidth
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. Cheers, Richard ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] Configure as_echo fix
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. :-) 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. Cheers, Richard ___ 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 7/2/09 3:43 PM, H. Langos wrote: Could you check if it still does what it was is supposed to do? :-) It looks fine, and my iPod still works, and didn't even have to reboot it for it to show my 30640 files. :-) 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 That diff looks good to me. It may be better to avoid merges among branches. Yeah, sorry about that. I won't be doing that again (and I'll be less eager to push commits I did). Cheers, Richard ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] Configure as_echo fix
On 7/3/09 10:55 PM, H. Langos wrote: But it seems that autoconf itself is not covered by the posix standard. I assumed you already knew that. :-) Where did you find the hint to replace echo $ECHO_N by $as_echo_n? From the generated configure script. I wouldn't be surprised if the AC_MSG_* macro's use $as_echo internally. Using the macro's is probably more future proof. I'll take another swing at it when I have more time. Cheers, Richard ___ 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, July 1, 2009 16:13, Jacinta Richardson wrote: I imagine that the author didn't intend that effect of calling the subroutine that way. Absolutely right. 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. I agree. Cheers, Richard (learning all the time) ___ 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, June 19, 2009 10:27, H. Langos wrote: Good thing you mention tunes2pod. Please try to make your changes optional. Something like a --merge option to express that you are going to merge iTunesDB and GNUtunesDB.xml I thought about this myself, but we would have to make this a parameter in .gnupodrc instead because of the automatic tunes2pod run by the other tools. The reason that I didn't implement it, is that there is no real downside to do the merging. The attributes in iTunesDB always overwrite those in GNUtunesDB.xml. If they are the same, no problem. If a file is in iTunesDB and not in GNUtunesDB.xml, no problem either. Let me know if you absolutely want it to be optional and I'll make it so. Cheers, Richard ___ 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, June 19, 2009 11:07, H. Langos wrote: Maybe the merge code should only be active if your memory saving feature is active? That makes a lot of sense, and it easy to implement. :-) I'll post another patch tonight. Cheers, Richard ___ 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 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. :-)
Cheers,
Richard
diff --git a/doc/gnupodrc.example b/doc/gnupodrc.example
index e290224..27b6bc0 100644
--- a/doc/gnupodrc.example
+++ b/doc/gnupodrc.example
@@ -33,24 +33,38 @@
# NON GLOBAL OPTIONS ##
# *** mktunes.pl ***
+
## Specify the iPods name
# mktunes.ipod-name = Wurstli
+## Set --volume boost to +10 percent
+# mktunes.volume = +10
+
+## Enforce iPod serial number:
+# mktunes.fwguid = 000ba3100310abcf
+
+## Only keep some attributes to make the iTunesDB fit inside small RAM
+## The minimum attributes needed by the iPod are path and title
+## Valid attributes are:
+## title path album artist genre fdesc eq comment category composer group
+## desc podcastguid podcastrss chapterdata subtitle tvshow tvepisode
+## tvnetwork albumartist artistthe keywords sorttitle sortalbum
+## sortalbumartist sortcomposer sorttvshow
+# low_ram_attr = path title artist album
# *** on the go sync (V2 Firmware) ***
+
## Uncomment this to skip 'on-the-go' sync
# otgsync.nosync = 1
# *** tunes2pod.pl ***
+
## Uncomment to set '--force' switch to true (DANGEROUS)
# tunes2pod.force = 1
-
-# *** mktunes.pl ***
-## Set --volume boost to +10 percent
-# mktunes.volume = +10
-## Enforce iPod serial number:
-# mktunes.fwguid = 000ba3100310abcf
+## Setting the low_ram_attr option above causes tunes2pod.pl to sync
+## the attibutes in iTunesDB with those in GNUtunesDB.xml to make sure
+## attributes not present in iTunesDB will be lost
# *** gnupod_search.pl ***
diff --git a/src/ext/Mktunes.pm b/src/ext/Mktunes.pm
index c47d679..b503058 100644
--- a/src/ext/Mktunes.pm
+++ b/src/ext/Mktunes.pm
@@ -34,7 +34,7 @@ package GNUpod::Mktunes;
#
# Create and write the iTunesDB file
sub WriteItunesDB {
- my($self) = @_;
+ my($self,%args) = @_;
my $mhbd_size = 0;
my $mhsd_size = 0;
@@ -52,7 +52,7 @@ package GNUpod::Mktunes;
$mhsd_size = tell(ITUNES);
print ITUNES
GNUpod::iTunesDB::mk_mhlt({songs=$self-GetFileCount});
foreach my $item (@{$self-GetFiles}) {
- print ITUNES $self-AssembleMhit($item);
+ print ITUNES $self-AssembleMhit(object=$item,
keep=$args{keep});
print \r $i files assembled if ($i++ % 96 == 0);
}
$mhsd_size = tell(ITUNES)-$mhsd_size;
@@ -267,7 +267,9 @@ package GNUpod::Mktunes;
#
# Builds a single mhit with mhod childs
sub AssembleMhit {
- my($self, $object) = @_;
+ my($self, %args) = @_;
+ my $object = $args{object};
+ my $keep= $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 @@ package GNUpod::Mktunes;
foreach my $key (sort keys(%$object)) {
my $value = $object-{$key};
next unless $value; # Do not write empty values
+ next if (scalar keys %$keep !$keep-{$key}); # 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;
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});
diff --git a/src/mktunes.pl b/src/mktunes.pl
index fab4ce3..a35ef62 100644
--- a/src/mktunes.pl
+++ b/src/mktunes.pl
@@ -41,7 +41,7 @@ print mktunes.pl ###__VERSION__### (C) Adrian Ulrich\n;
$opts{mount}
Re: [Bug-gnupod] mktunes.pl creates corrupt iTunesDB ?
On Thu, June 18, 2009 08:22, H. Langos wrote: Did I mention before that I hate perl? :-) In about every other post to this list. ;-) To me, the things about perl that I sometimes hate let me very quickly write code that does what I want at other times. When I started with the tunes2pod code I thought damn, this is going to be very hard to do. Then one hour later I was done and it worked. :-) 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. :-) They are. I'm very good at copy-and-paste and mimicking other people's style. I realize that most of the gnupod code is not yours, so don't blame me for using Adrian's coding style. :-) Cheers, Richard ___ 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, June 17, 2009 10:41, H. Langos wrote:
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.
I'll fix that. I was already thinkign you wouldn't like the keepattr name.
:-)
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.
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.
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.
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.
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.
Shouldn't that be :
$mktunes-WriteItunesDB( {Keep = $opts{'keepattr'}} );
Absolutely. I already noticed that, and was quite surprised it worked
without the {}.
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.
Will do.
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
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.
Cheers,
Richard
___
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 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});
While the form with the {} can be used as:
($self,$args) = @_;
@keep=split(/[ ,]+/, $args-{Keep});
Both forms are in use in the gnupod code at the moment, I just picked
the first..
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.
Cheers,
Richard
? .gnupod_version
? Makefile
? autom4te.cache
? config.log
? config.status
? configure
Index: doc/gnupodrc.example
===
RCS file: /sources/gnupod/gnupod/doc/gnupodrc.example,v
retrieving revision 1.7
diff -u -r1.7 gnupodrc.example
--- doc/gnupodrc.example5 Jun 2009 12:55:56 - 1.7
+++ doc/gnupodrc.example17 Jun 2009 19:56:32 -
@@ -51,6 +51,14 @@
# mktunes.volume = +10
## Enforce iPod serial number:
# mktunes.fwguid = 000ba3100310abcf
+## Only keep some attributes to make the iTunesDB fit inside small RAM
+## The minimum attributes needed by the iPod are path and title
+## Valid attributes are:
+## title path album artist genre fdesc eq comment category composer group
+## desc podcastguid podcastrss chapterdata subtitle tvshow tvepisode
+## tvnetwork albumartist artistthe keywords sorttitle sortalbum
+## sortalbumartist sortcomposer sorttvshow
+# low_ram_attr = path title artist album
# *** gnupod_search.pl ***
Index: src/mktunes.pl
===
RCS file: /sources/gnupod/gnupod/src/mktunes.pl,v
retrieving revision 1.86
diff -u -r1.86 mktunes.pl
--- src/mktunes.pl 8 Dec 2007 10:26:08 - 1.86
+++ src/mktunes.pl 17 Jun 2009 19:56:32 -
@@ -41,7 +41,7 @@
$opts{mount} = $ENV{IPOD_MOUNTPOINT};
GetOptions(\%opts, version, help|h, ipod-name|n=s, mount|m=s,
volume|v=i, energy|e, fwguid|g=s);
-GNUpod::FooBar::GetConfig(\%opts, {'ipod-name'='s', mount='s', volume='i',
energy='b', fwguid='s', model='s'}, mktunes);
+GNUpod::FooBar::GetConfig(\%opts, {'ipod-name'='s', mount='s', volume='i',
energy='b', fwguid='s', model='s', low_ram_attr='s'}, mktunes);
$opts{'ipod-name'} ||= GNUpod ###__VERSION__###;
@@ -69,7 +69,12 @@
GNUpod::XMLhelper::doxml($con-{xml}) or usage(Could not read
$con-{xml}, did you run gnupod_INIT.pl ?);
print \r .$mktunes-GetFileCount. files parsed, assembling
iTunesDB...\n;
- $mktunes-WriteItunesDB;
+
+ my $keep = {};
+ foreach(split(/[ ,]+/,$opts{'low_ram_attr'})) {
+ $keep-{$_}++;
+ }
+ $mktunes-WriteItunesDB(keep=$keep);
if($fwguid) {
my $k = GNUpod::Hash58::HashItunesDB(FirewireId=$fwguid,
iTunesDB=$con-{itunesdb});
Index: src/tunes2pod.pl
===
RCS file: /sources/gnupod/gnupod/src/tunes2pod.pl,v
retrieving revision 1.49
diff -u -r1.49 tunes2pod.pl
--- src/tunes2pod.pl2 Feb 2008 11:42:58 - 1.49
+++ src/tunes2pod.pl17 Jun 2009 19:56:32 -
@@ -35,6 +35,8 @@
use vars qw(%opts);
$| = 1;
+my $xml_files_parsed=0;
+my $gtdb = {};
print tunes2pod.pl Version ###__VERSION__### (C) Adrian Ulrich\n;
@@ -65,6 +67,11 @@
exit(1);
}
+ print Parsing XML document...\n;
+ GNUpod::XMLhelper::doxml($con-{xml}) or usage(Could not read
$con-{xml}, did you run gnupod_INIT.pl ?);
+ GNUpod::XMLhelper::resetxml;
+ print \r .$xml_files_parsed. files parsed, converting
iTunesDB...\n;
+
open(ITUNES, $con-{itunesdb}) or usage(Could not open
$con-{itunesdb});
while(ITUNES) {}; sysseek(ITUNES,0,0); # the iPod is a slw
mass-storage device, slurp it into the fs-cache
@@ -197,7 +204,7 @@
sub MhitEnd {
my($self, %args) = @_;
if($self-{mode} == MODE_SONGS) {
- GNUpod::XMLhelper::mkfile({file=$self-{ctx}});
# Add file element to xml
+ GNUpod::XMLhelper::mkfile({file=MergeGtdbCtx($self-{ctx})});
# Add file element to xml
$self-{ctx} = ();
# And drop this buffer
my $i = ++$self-{count_songs_done};
if($i % 32 == 0) {
@@ -344,11 +351,35 @@
$self-ResetPlaylists; # Resets podcast and normal playlist data
}
-
-
-
-
-
+#
+# Merge GNUtunesDB with ctx
+sub MergeGtdbCtx {
+
Re: [Bug-gnupod] mktunes.pl creates corrupt iTunesDB ?
Patch 2 bound the iTunesDB and GNUtunes.xml on id. Since gnupod
regenerates the id field on every mktunes run, other software might do
the same. So I figured binding them on the path attribute would be a
better idea.
Cheers,
Richard
? .gnupod_version
? Makefile
? autom4te.cache
? config.log
? config.status
? configure
Index: doc/gnupodrc.example
===
RCS file: /sources/gnupod/gnupod/doc/gnupodrc.example,v
retrieving revision 1.7
diff -u -r1.7 gnupodrc.example
--- doc/gnupodrc.example5 Jun 2009 12:55:56 - 1.7
+++ doc/gnupodrc.example18 Jun 2009 04:44:09 -
@@ -51,6 +51,14 @@
# mktunes.volume = +10
## Enforce iPod serial number:
# mktunes.fwguid = 000ba3100310abcf
+## Only keep some attributes to make the iTunesDB fit inside small RAM
+## The minimum attributes needed by the iPod are path and title
+## Valid attributes are:
+## title path album artist genre fdesc eq comment category composer group
+## desc podcastguid podcastrss chapterdata subtitle tvshow tvepisode
+## tvnetwork albumartist artistthe keywords sorttitle sortalbum
+## sortalbumartist sortcomposer sorttvshow
+# low_ram_attr = path title artist album
# *** gnupod_search.pl ***
Index: src/mktunes.pl
===
RCS file: /sources/gnupod/gnupod/src/mktunes.pl,v
retrieving revision 1.86
diff -u -r1.86 mktunes.pl
--- src/mktunes.pl 8 Dec 2007 10:26:08 - 1.86
+++ src/mktunes.pl 18 Jun 2009 04:44:09 -
@@ -41,7 +41,7 @@
$opts{mount} = $ENV{IPOD_MOUNTPOINT};
GetOptions(\%opts, version, help|h, ipod-name|n=s, mount|m=s,
volume|v=i, energy|e, fwguid|g=s);
-GNUpod::FooBar::GetConfig(\%opts, {'ipod-name'='s', mount='s', volume='i',
energy='b', fwguid='s', model='s'}, mktunes);
+GNUpod::FooBar::GetConfig(\%opts, {'ipod-name'='s', mount='s', volume='i',
energy='b', fwguid='s', model='s', low_ram_attr='s'}, mktunes);
$opts{'ipod-name'} ||= GNUpod ###__VERSION__###;
@@ -69,7 +69,12 @@
GNUpod::XMLhelper::doxml($con-{xml}) or usage(Could not read
$con-{xml}, did you run gnupod_INIT.pl ?);
print \r .$mktunes-GetFileCount. files parsed, assembling
iTunesDB...\n;
- $mktunes-WriteItunesDB;
+
+ my $keep = {};
+ foreach(split(/[ ,]+/,$opts{'low_ram_attr'})) {
+ $keep-{$_}++;
+ }
+ $mktunes-WriteItunesDB(keep=$keep);
if($fwguid) {
my $k = GNUpod::Hash58::HashItunesDB(FirewireId=$fwguid,
iTunesDB=$con-{itunesdb});
Index: src/tunes2pod.pl
===
RCS file: /sources/gnupod/gnupod/src/tunes2pod.pl,v
retrieving revision 1.49
diff -u -r1.49 tunes2pod.pl
--- src/tunes2pod.pl2 Feb 2008 11:42:58 - 1.49
+++ src/tunes2pod.pl18 Jun 2009 04:44:09 -
@@ -35,6 +35,8 @@
use vars qw(%opts);
$| = 1;
+my $xml_files_parsed=0;
+my $gtdb = {};
print tunes2pod.pl Version ###__VERSION__### (C) Adrian Ulrich\n;
@@ -65,6 +67,11 @@
exit(1);
}
+ print Parsing XML document...\n;
+ GNUpod::XMLhelper::doxml($con-{xml}) or usage(Could not read
$con-{xml}, did you run gnupod_INIT.pl ?);
+ GNUpod::XMLhelper::resetxml;
+ print \r .$xml_files_parsed. files parsed, converting
iTunesDB...\n;
+
open(ITUNES, $con-{itunesdb}) or usage(Could not open
$con-{itunesdb});
while(ITUNES) {}; sysseek(ITUNES,0,0); # the iPod is a slw
mass-storage device, slurp it into the fs-cache
@@ -197,7 +204,7 @@
sub MhitEnd {
my($self, %args) = @_;
if($self-{mode} == MODE_SONGS) {
- GNUpod::XMLhelper::mkfile({file=$self-{ctx}});
# Add file element to xml
+ GNUpod::XMLhelper::mkfile({file=MergeGtdbCtx($self-{ctx})});
# Add file element to xml
$self-{ctx} = ();
# And drop this buffer
my $i = ++$self-{count_songs_done};
if($i % 32 == 0) {
@@ -344,11 +351,35 @@
$self-ResetPlaylists; # Resets podcast and normal playlist data
}
-
-
-
-
-
+#
+# Merge GNUtunesDB with ctx
+sub MergeGtdbCtx {
+ my($Ctx) = @_;
+ return $Ctx unless $Ctx-{path} $gtdb-{$Ctx-{path}};
+ return {%{$gtdb-{$Ctx-{path}}}, %$Ctx};
+}
+
+#
+# Called by doxml if it finds a new file tag
+sub newfile {
+ my($item) = @_;
+ my $file = $item-{file};
+ my $path = $file-{path};
+
+ $xml_files_parsed++;
+ print \r .$xml_files_parsed. files parsed if $xml_files_parsed %
96 == 0;
+
+ return unless $path;
+ $gtdb-{$path} = {};
+ foreach(keys(%$file)){
+ $gtdb-{$path}-{$_}=$file-{$_};
+ }
+}
+
Re: [Bug-gnupod] mktunes.pl creates corrupt iTunesDB ?
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. :-)
These are the mhods that gnupod supports:
my %mhod_id = ( title=1, path=2, album=3, artist=4, genre=5,
fdesc=6, eq=7, comment=8, category=9, composer=12, group=13,
desc=14, podcastguid=15, podcastrss=16,
chapterdata=17, subtitle=18, tvshow=19, tvepisode=20,
tvnetwork=21, albumartist=22, artistthe=23,
keywords=24, sorttitle=27, sortalbum=28, sortalbumartist=29,
sortcomposer=30, sorttvshow=31);
I've determined that all you really need is the path and title. This
created a 25MB iTunesDB. That's only 57% of what I started with. I've
settled for keeping these mhods:
path
artist
title
album
desc
This gave me an iTunesDB of 32MB (34MB with my title patch) which works
just fine on my 64MB iPod Video.
Since different users will want to keep different attributes I went for
a keepattr option in gnupodrc. 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.
Cheers,
Richard
? .gnupod_version
? Makefile
? autom4te.cache
? config.log
? config.status
? configure
Index: doc/gnupodrc.example
===
RCS file: /sources/gnupod/gnupod/doc/gnupodrc.example,v
retrieving revision 1.7
diff -u -r1.7 gnupodrc.example
--- doc/gnupodrc.example5 Jun 2009 12:55:56 - 1.7
+++ doc/gnupodrc.example16 Jun 2009 20:01:51 -
@@ -51,6 +51,14 @@
# mktunes.volume = +10
## Enforce iPod serial number:
# mktunes.fwguid = 000ba3100310abcf
+## Only keep some attributes to make the iTunesDB size as small as possible
+## The minimum attributes needed by the iPod are path and title
+## Valid attributes are:
+## title path album artist genre fdesc eq comment category composer group
+## desc podcastguid podcastrss chapterdata subtitle tvshow tvepisode
+## tvnetwork albumartist artistthe keywords sorttitle sortalbum
+## sortalbumartist sortcomposer sorttvshow
+# keepattr = path title artist album
# *** gnupod_search.pl ***
Index: src/mktunes.pl
===
RCS file: /sources/gnupod/gnupod/src/mktunes.pl,v
retrieving revision 1.86
diff -u -r1.86 mktunes.pl
--- src/mktunes.pl 8 Dec 2007 10:26:08 - 1.86
+++ src/mktunes.pl 16 Jun 2009 20:01:51 -
@@ -41,7 +41,7 @@
$opts{mount} = $ENV{IPOD_MOUNTPOINT};
GetOptions(\%opts, version, help|h, ipod-name|n=s, mount|m=s,
volume|v=i, energy|e, fwguid|g=s);
-GNUpod::FooBar::GetConfig(\%opts, {'ipod-name'='s', mount='s', volume='i',
energy='b', fwguid='s', model='s'}, mktunes);
+GNUpod::FooBar::GetConfig(\%opts, {'ipod-name'='s', mount='s', volume='i',
energy='b', fwguid='s', model='s', keepattr='s'}, mktunes);
$opts{'ipod-name'} ||= GNUpod ###__VERSION__###;
@@ -69,7 +69,7 @@
GNUpod::XMLhelper::doxml($con-{xml}) or usage(Could not read
$con-{xml}, did you run gnupod_INIT.pl ?);
print \r .$mktunes-GetFileCount. files parsed, assembling
iTunesDB...\n;
- $mktunes-WriteItunesDB;
+ $mktunes-WriteItunesDB(Keep=$opts{'keepattr'});
if($fwguid) {
my $k = GNUpod::Hash58::HashItunesDB(FirewireId=$fwguid,
iTunesDB=$con-{itunesdb});
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.pm 6 Oct 2007 07:26:52 - 1.6
+++ src/ext/Mktunes.pm 16 Jun 2009 20:01:51 -
@@ -34,7 +34,7 @@
#
# Create and write the iTunesDB file
sub WriteItunesDB {
- my($self) = @_;
+ my($self,%args) = @_;
my $mhbd_size = 0;
my $mhsd_size = 0;
@@ -52,7 +52,7 @@
$mhsd_size = tell(ITUNES);
print ITUNES
GNUpod::iTunesDB::mk_mhlt({songs=$self-GetFileCount});
foreach my $item (@{$self-GetFiles}) {
- print ITUNES $self-AssembleMhit($item);
+ print ITUNES $self-AssembleMhit(Item=$item,
Keep=$args{Keep});
print \r $i files assembled if ($i++ % 96 == 0);
}
$mhsd_size = tell(ITUNES)-$mhsd_size;
@@ -267,7 +267,9 @@
#
# Builds a single mhit with mhod childs
sub AssembleMhit {
- my($self, $object) = @_;
+ my($self, %args) = @_;
+ my $object = $args{Item};
Re: [Bug-gnupod] Do not stretch artwork
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. Cheers, Richard ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] Do not stretch artwork
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? Do you want to use the color of the iPod housing? I was going for the background of the iPod UI. On my iPod Video the artwork is never displayed full screen. There is always a white border. I guess e can should make it configurable in the gnupodrc. Cheers, Richard ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
[Bug-gnupod] Do not stretch artwork
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.
Cheers,
Richard
Index: src/ext/ArtworkDB.pm
===
RCS file: /sources/gnupod/gnupod/src/ext/ArtworkDB.pm,v
retrieving revision 1.22
diff -u -r1.22 ArtworkDB.pm
--- src/ext/ArtworkDB.pm5 Jun 2009 12:55:56 - 1.22
+++ src/ext/ArtworkDB.pm14 Jun 2009 21:02:16 -
@@ -174,7 +174,7 @@
$self-{fbimg}-{source_size} = (-s $file) or return 0; # no
thanks
foreach my $mr (@$mode) {
my $buff = '';
- 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:-);
binmode(IM);
while(IM) { $buff .= $_ }
close(IM);
___
Bug-gnupod mailing list
Bug-gnupod@nongnu.org
http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] mktunes.pl creates corrupt iTunesDB ?
The results I got today were not consistent with yesterday (ok iTunesDBs
would now be not ok). I learned a lot about the binary format, and
figured out that by messing with the ArtworkDB (for the performance
tests) the dbid_1 numbers were now out of whack. However, restoring the
whole iPod_Control/Artwork directory from yesterday didn't help.
So I decided to clear the iPod_Control/Artwork directory and take out
the dbid_1, artworkcnt and has_artwork parameters from my GNUtunesDB.xml
files. I had to do a complete new binary search to find the following ok
- ok - not_ok sequence:
http://richard.vdberg.org/gnupod/no_artwork/ok/11124/iTunesDB
http://richard.vdberg.org/gnupod/no_artwork/ok/11125/iTunesDB
http://richard.vdberg.org/gnupod/no_artwork/not_ok/11126/iTunesDB
This time file number 11126 seems to be the problem:
file addtime=3327445665 album=Love Train - The Sound Of
Philadelphia - Disc 2 artist=Billy Paul bitrate=215 cdnum=0
cds=0 comment= compilation=1 composer=
desc=/d01/mp3/marcel/Love Train/The Sound Of Philadelphia/32 - Billy
Paul - Thanks For Saving My Life.mp3 fdesc=MPEG 1 layer 3 file
filesize=4813000 genre=Soul id=11152 mediatype=1
path=:iPod_Control:Music:f23:g0_For_Saving_My_Life.mp3 playcount=0
songnum=12 songs=0 soundcheck=5070 srate=44100 time=178311
title=Thanks For Saving My Life volume=0 year=2008 /
On 6/13/09 12:43 PM, H. Langos wrote:
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.
Interesting idea. See attached patch. It does make the diff a whole lot
easier to read. And it made a difference as well. With this patch
applied 11126 suddenly worked.
During the binary search for the next limit I found that if an iTunesDB
does not work right after I unplug the USB, it *might* work after a
reset of the iPod. How weird is that? I verified that after the reboot
the iTunesDB is exactly (cmp -bl) the same as before.
I'm now starting to think it's a RAM issue. According to
http://ipodlinux.org/wiki/Generations#Fifth_Generation_.285G.29_.2F_Fifth_Generation_Enhanced_.285.5G.29
my 30GB turned 240GB iPod has 32MB of RAM. Maybe I should try to get a
hold of a 60GB/80GB version (64GB of RAM)?
Using a binary search including a reset cycle, I was able to get it to
work with 17759 files (then I got bored):
25026442 not_ok/18053/iTunesDB-plid
25826240 not_ok/18640/iTunesDB-plid
28968870 not_ok/20987/iTunesDB-plid
42047276 not_ok/30415/iTunesDB-plid
22566800 ok/16293/iTunesDB-plid
24192148 ok/17466/iTunesDB-plid
24621122 ok/17759/iTunesDB-plid
You can find the files here: http://richard.vdberg.org/gnupod/no_artwork/
I used the plid extension to show I've used the decrement-plid patch
to produce those iTunesDBs.
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.pm 6 Oct 2007 07:26:52 - 1.6
+++ src/ext/Mktunes.pm 13 Jun 2009 17:05:41 -
@@ -12,7 +12,7 @@
my($class,%args) = @_;
my $self = { Connection=$args{Connection}, Mode=MODE_ADDFILE,
Artwork=$args{Artwork},
-ArrayFiles = [], CountFiles = 0, Sequence = 0,
iPodName = $args{iPodName},
+ArrayFiles = [], CountFiles = 0, Sequence = 0,
PlSequence = 0x, iPodName = $args{iPodName},
MasterPlaylist = [], Playlists = {},
SmartPlaylists = {},
FuzzyDb_Normal = {}, FuzzyDb_Lowercase = {} };
bless($self,$class);
@@ -91,6 +91,8 @@
sub GetFileCount{ my($self) = @_; return $self-{CountFiles};
}
# Increments Sequence counter
sub GetNextId { my($self) = @_; return ++$self-{Sequence};
}
+ # Decrements PlSequence counter
+ sub GetPrevId { my($self) = @_; return --$self-{PlSequence};
}
# Dispatch connector
sub GetConnection { my($self) = @_; return $self-{Connection}
}
# Returns array to files
@@ -240,7 +242,7 @@
foreach my $fqid (@{$cont}) {
- my $current_id = $self-GetNextId;
+ my $current_id = $self-GetPrevId;
my $current_mhod =
GNUpod::iTunesDB::mk_mhod({fqid=$fqid});
my $current_mhip =
GNUpod::iTunesDB::mk_mhip({childs = 1, plid = $current_id, sid=$fqid,
size=length($current_mhod)});
next unless (defined($current_mhod)
defined($current_mhip));
___
Re: [Bug-gnupod] 4th generation iPod Nano
On Fri, May 29, 2009 14:16, H. Langos wrote: It certainly wouldn't hurt to put some iTunesDB files away to have some data for verification if somebody sits down to reverse engineer that part of the iTunesDB format. I don't have the Nano anymore (it's on a plane to a sunny destination), but I can always borrow it later and make the dumps you suggested (my own approach was rather limited). It's rather interesting that the Nano didn't seem to mind the type 32 mhods were missing from the iTunesDB. Cheers, Richard ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] 4th generation iPod Nano
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.
Cheers,
Richard
? .gnupod_version
? Makefile
? autom4te.cache
? config.log
? config.status
? configure
? nano_4g
Index: doc/gnupod.html
===
RCS file: /sources/gnupod/gnupod/doc/gnupod.html,v
retrieving revision 1.34
diff -u -r1.34 gnupod.html
--- doc/gnupod.html 17 Feb 2008 09:14:04 - 1.34
+++ doc/gnupod.html 28 May 2009 19:11:42 -
@@ -943,7 +943,7 @@
!--docid::SEC17::--
P
-GNUpod can write cover artwork for video, nano and late 2007-nano iPods. The
internal image format is model specific, so you should give
+GNUpod can write cover artwork for video and nano iPods. The internal image
format is model specific, so you should give
GNUpod a hint about the image format it should use.
/PP
@@ -954,6 +954,8 @@
TABLEtrtdnbsp;/tdtd class=examplepremodel = nano
/pre/td/tr/tableLate 2007-nanos need this setting:
TABLEtrtdnbsp;/tdtd class=examplepremodel = nano_3g
+/pre/td/tr/tableLate 2008-nanos need this setting:
+TABLEtrtdnbsp;/tdtd class=examplepremodel = nano_4g
/pre/td/tr/table/PP
To specify a cover while adding files you'd use the CODE--artwork/CODE
switch of CODEgnupod_addsong.pl/CODE. Example:
Index: doc/gnupod.info
===
RCS file: /sources/gnupod/gnupod/doc/gnupod.info,v
retrieving revision 1.33
diff -u -r1.33 gnupod.info
--- doc/gnupod.info 17 Feb 2008 09:14:04 - 1.33
+++ doc/gnupod.info 28 May 2009 19:11:42 -
@@ -667,6 +667,8 @@
model = nano
Late 2007-nanos need this setting:
model = nano_3g
+ Late 2008-nanos need this setting:
+ model = nano_4g
To specify a cover while adding files you'd use the `--artwork'
switch of `gnupod_addsong.pl'. Example:
Index: doc/gnupod.texi
===
RCS file: /sources/gnupod/gnupod/doc/gnupod.texi,v
retrieving revision 1.41
diff -u -r1.41 gnupod.texi
--- doc/gnupod.texi 24 Mar 2009 16:54:41 - 1.41
+++ doc/gnupod.texi 28 May 2009 19:11:43 -
@@ -684,7 +684,7 @@
@node Adding cover artwork
@section Adding cover artwork
-GNUpod can write cover artwork for video, nano and late 2007-nano iPods. The
internal image format is model specific, so you should give
+GNUpod can write cover artwork for video and nano iPods. The internal image
format is model specific, so you should give
GNUpod a hint about the image format it should use.
If you own a video (compatible) iPod, set:
@@ -700,6 +700,10 @@
@example
model = nano_3g
@end example
+Late 2008-nanos need this setting:
+...@example
+model = nano_4g
+...@end example
To specify a cover while adding files you'd use the @co...@w{--artwork}}
switch of @co...@w{gnupod_addsong.pl}}. Example:
Index: doc/gnupodrc.example
===
RCS file: /sources/gnupod/gnupod/doc/gnupodrc.example,v
retrieving revision 1.6
diff -u -r1.6 gnupodrc.example
--- doc/gnupodrc.example28 Nov 2007 06:21:19 - 1.6
+++ doc/gnupodrc.example28 May 2009 19:11:43 -
@@ -19,6 +19,7 @@
## * video (default)
## * nano(pre-2007 nanos)
## * nano_3g (the late 2007 nano)
+## * nano_4g (the late 2008 nano)
# model = video
## Let GNUpod call mktunes.pl itself.
Index: src/ext/ArtworkDB.pm
===
RCS file: /sources/gnupod/gnupod/src/ext/ArtworkDB.pm,v
retrieving revision 1.21
diff -u -r1.21 ArtworkDB.pm
--- src/ext/ArtworkDB.pm2 Feb 2008 11:30:38 - 1.21
+++ src/ext/ArtworkDB.pm28 May 2009 19:11:43 -
@@ -35,7 +35,10 @@
use constant MODE_PARSED= 300;
# Artwork profiles:
- my $profiles = { 'nano_3g' = [ { height=320, width=320,
storage_id=1060, bpp=16, }, { height=128, width=128, storage_id=1055,
bpp=16, },
+ my $profiles = { 'nano_4g' = [ { height=128, width=128,
storage_id=1055, bpp=16, }, { height=128, width=128, storage_id=1068,
bpp=16, },
+ { height=240, width=240,
storage_id=1071, bpp=16, }, { height=50, width=50, storage_id=1074,
bpp=16, },
+ { height=80, width=80,
storage_id=1078, bpp=16, }, { height=240, width=240, storage_id=1084,
bpp=16, }, ],
+'nano_3g' = [ { height=320, width=320,
storage_id=1060, bpp=16, }, { height=128, width=128, storage_id=1055,
bpp=16, },
{ height=56, width=56,
storage_id=1061, bpp=16, drop=112}
],
'classic' = [ { height=320, width=320,
storage_id=1060, bpp=16, }, { height=128, width=128
Re: [Bug-gnupod] 4th generation iPod Nano
On 5/27/09 11:48 AM, H. Langos wrote: On Wed, May 27, 2009 at 07:29:11AM +0200, Richard van den Berg wrote: I temporarily have access to a 4th generation iPod Nano. During the gnupod_INIT I see a bunch of: /usr/bin/tunes2pod: skipping unknown entry of type '32' Should I see where these warnings come from, or is that harmless? Dunno. I'd look into it. And see how gtkpod/libgpod handles it. Type 32 mhod is related to video files (one appears for each file). This is confirmed by some posts on ipodlinux.org I found in the google cache (www.ipodlinux.org is down). It seems no one knows what type 32 mhod is exactly. Libgpod does not have support for it. I don't know how it handles unknown mhod types though. Gnupod removes them, which doesn't seem to bother my iPod Nano. I made some backups of the iTunesDB before and after loading video files with iTunes. A hex editor doesn't give me much insight. Let me know if you want to take a peek yourself. Cheers, Richard ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] 4th generation iPod Nano
On 27-5-2009 11:48, H. Langos wrote: Here's a commit email regarding new artwork formats for the nano4g from libgpod: http://sourceforge.net/mailarchive/message.php?msg_id=E1LB8Vz-0005Dh-9Y%40d5vjzd1.ch3.sourceforge.com which has been fixed a little later http://gtkpod.svn.sourceforge.net/viewvc/gtkpod/libgpod/trunk/src/itdb_device.c?r1=2184r2=2187 Great research, thanks. I took the values from that last post and they worked just fine. The nano_4g is an awesome looking iPod.. too bad it's only 16GB. I'll post a full patch including the documentation side later. Cheers, Richard ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
[Bug-gnupod] 4th generation iPod Nano
I temporarily have access to a 4th generation iPod Nano. During the
gnupod_INIT I see a bunch of:
/usr/bin/tunes2pod: skipping unknown entry of type '32'
Should I see where these warnings come from, or is that harmless?
One thing I will look into is the artwork. Setting the model to nano_3g
makes the coverflow work (awesome!), but does not display the artwork
during all other views. In ArtworkDB.pm I see:
# Artwork profiles:
my $profiles = { 'nano_3g' = [ { height=320, width=320,
storage_id=1060, bpp=16, }, { height=128, width=128,
storage_id=1055, bpp=16, },
{ height=56, width=56,
storage_id=1061, bpp=16,
drop=112} ],
'classic' = [ { height=320, width=320,
storage_id=1060, bpp=16, }, { height=128, width=128,
storage_id=1055, bpp=16, },
{ height=56, width=56,
storage_id=1061, bpp=16,
drop=112} ],
'nano'= [ { height=100, width=100,
storage_id=1027, bpp=16, }, { height= 42, width= 42,
storage_id=1031, bpp=16, }, ],
'video' = [ { height=200, width=200,
storage_id=1029, bpp=16, }, { height=100, width=100,
storage_id=1028, bpp=16, }, ],
};
Is there an easy way to figure out the right values for the nano_4g ? Or
will I have to hexdump the ArtworkDB myself?
Cheers,
Richard
___
Bug-gnupod mailing list
Bug-gnupod@nongnu.org
http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] gnupod_addsong.pl --artwork without ImageMagick
On Mon, May 11, 2009 13:21, H. Langos wrote: Artwork handling on the iPod is still kind of dark voodoo to me. I only made a couple of patches to it. You are welcome to improve the error hendling whereever pnupod calls some ImageMagic tools. Probably calling convert somewhere in ArtworkDB.pm There is of course Image::Magick that we should probably use instead. If/when I'll look at the code, I'll work it in. Cheers, Richard ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] DESC field in iTunesDB / lyrics display
On 5/9/09 5:04 PM, H. Langos wrote: Thats pretty close to what I use (iPod nano (3rd generation)) but since artwork is displayed all the time, there is no separate cycle position for it. What do you mean by all the time? My iPod shows the artwork during the volume and position display, but not during the rating one. Are you sure that the postings you've read about lyrics display where talking about your model? Yes. http://forums.macrumors.com/showthread.php?t=160916 suggests that the iPod reads the lyrics from the mp3 and not the iTunesDB. That would explain why my test failed. I only set the lyrics_flag, but did not add a USLT tag. I can confirm that iTunes also adds a USLT tag when you add lyrics to an mp3. I just did another test with 2 files with USLT tags. When the lyrics_flag is 0, no lyrics are shown. When it is 1, the lyrics are shown! So gnupod should really set the lyrics_flag when a USLT is present in mp3 files. This also means that filling the description field with the USLT info for non-podcast mp3s is pretty useless. I don't have enough experience with podcasts to check if the description field or USLT tag is shown for those files. Cheers, Richard ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] DESC field in iTunesDB / lyrics display
On 5/10/09 6:00 PM, Richard van den Berg wrote: What do you mean by all the time? My iPod shows the artwork during the volume and position display, but not during the rating one. I just checked, and the artwork is also showing during the rating view. The artwork view on my iPod shows the artwork fullscreen, and presumably you can browse through multiple artwork images if present in the file (I don't have such files). Cheers, Richard ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] Patch to support ReplayGain / mp3gain
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.
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...
That depends. It gives the user some manual control over the desired
volume to use. If someone feels that applying the automatic algorithm
makes a track too loud or too quiet, he can manually set an RVA value to
compensate for it. This could be preferred over adjusting the normalized
value directly because when the files are rescanned by the normalization
algorithm, the RVA tag will not be reset. This is how iTunes does it
(iTunNORM is set by the Sound Check algorithm, while RVAD can be set
manually with a volume slider, they are both combined at playback). I'm
not saying I prefer combining these tags, but it's how the iPod works:
the Sound Check and Volume values are combined at playback (which Sound
Check is enabled on the iPod). With my patch the Replay Gain data is
converted to the iTunesDB Sound Check value while gnupod already
translates RVA2 values the iTunesDB Volume value.
So far we've only established that the normalize software writes RVA2
tags (iTunes writes RVAD which gnupod currently ignores). Using both
normalize and mp3gain is silly and makes no sense, but would indeed
result in these two algorithms being used on top of each other unless
you disable Sound Check on the iPod.
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.
To have only ReplayGain and nothing else applied in the iPod, I will
have to not use the --max-vol-adj parameter and not use Sound Check,
right?
ReplayGain is stored as a Sound Check value, so you will have to enable
Sound Check on your iPod. Leave the --max-vol-adj alone so gnupod
ignores the RVA tags (0 is the default).
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.
Cheers,
Richard
___
Bug-gnupod mailing list
Bug-gnupod@nongnu.org
http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] Patch to support ReplayGain / mp3gain
On 5/9/09 9:14 AM, Frank Blendinger wrote:
[...]
gnupod_convert_OGG.pl uses Ogg::Vorbis::Header which may or may not
support the RG tags. If you send me an ogg file (privately) that
contains RG info I can check (and patch gnupod_convert_OGG.pl).
I've sent you a private mail on this, it should be easy to do.
Thanks for the file. The attached patch (adding 4 lines of code) takes
care of it.
Cheers,
Richard
diff -ru gnupod-rg-mp3/src/ext/FileMagic.pm gnupod-cvs/src/ext/FileMagic.pm
--- gnupod-rg-mp3/src/ext/FileMagic.pm 2009-05-09 11:17:53.0 +0200
+++ gnupod-cvs/src/ext/FileMagic.pm 2009-05-09 13:01:46.0 +0200
@@ -180,6 +180,10 @@
my $cf = ((split(/\//,$file))[-1]);
my @songa = pss($metastuff-{_TRACKNUM});
+ # Use track ReplayGain by default, use album ReplayGain if requested
+ my $rgtag = _REPLAYGAIN_TRACK_GAIN;
+ $rgtag = _REPLAYGAIN_ALBUM_GAIN if($flags-{'rgalbum'});
+
$rh{artist}= getutf8($metastuff-{_ARTIST} || Unknown Artist);
$rh{album} = getutf8($metastuff-{_ALBUM} || Unknown Album);
$rh{title} = getutf8($metastuff-{_TITLE} || $cf || Unknown
Title);
@@ -188,6 +192,7 @@
$rh{songnum} = int($songa[0]);
$rh{comment} = getutf8($metastuff-{_COMMENT} ||
$metastuff-{FORMAT}. file);
$rh{fdesc} = getutf8($metastuff-{_VENDOR} || Converted using
$encoder);
+ $rh{soundcheck} = _parse_ReplayGain($metastuff-{$rgtag}) || ;
$rh{mediatype} = int($metastuff-{_MEDIATYPE} || MEDIATYPE_AUDIO);
return {ref=\%rh, encoder=$encoder,
codec=$NN_HEADERS-{$magic}-{ftyp} };
}
diff -ru gnupod-rg-mp3/src/gnupod_convert_OGG.pl
gnupod-cvs/src/gnupod_convert_OGG.pl
--- gnupod-rg-mp3/src/gnupod_convert_OGG.pl 2009-05-09 12:42:25.0
+0200
+++ gnupod-cvs/src/gnupod_convert_OGG.pl2009-05-09 12:40:27.0
+0200
@@ -62,6 +62,8 @@
print _TRACKNUM:.( ($ftag-comment('tracknum'))[0] |
($ftag-comment('tracknumber'))[0] ).\n;
print _COMMENT:.($ftag-comment('comment'))[0].\n;
+print
_REPLAYGAIN_TRACK_GAIN:.($ftag-comment('REPLAYGAIN_TRACK_GAIN'))[0].\n;
+print
_REPLAYGAIN_ALBUM_GAIN:.($ftag-comment('REPLAYGAIN_ABLUM_GAIN'))[0].\n;
print _MEDIATYPE:.(GNUpod::FileMagic::MEDIATYPE_AUDIO).\n;
print FORMAT:OGG\n;
}
___
Bug-gnupod mailing list
Bug-gnupod@nongnu.org
http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] DESC field in iTunesDB
On 5/9/09 3:52 PM, H. Langos wrote: 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 It's a 5th generation 30GB iPod with video. The last 3 digits of the serial number are SZ9 so it's not a 5.5 generation. I'm running firmware version 1.3 which seems to be the latest. Cheers, Richard ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] Patch to support ReplayGain / mp3gain
On 5/9/09 4:41 PM, H. Langos wrote: 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. From that URL: reached the conclusion that as the vast majority of implementations are using 89dB, we should take this infortunate situation into consideration and update the standard to 89dB Since you already came to the conclusion that mp3gain is about the only implementation of the Replay Gain algorithm, I'm sure it uses 89dB as well. From mp3gain.c: /* the TAG version of the suggested Track Gain should ALWAYS be based on the 89dB standard. So we don't modify the suggested gain change until this point */ So I guess it is safe to store Replay Gain info inside RVA2 tags. The more I think about it, the more it makes sense to use the nid3lib code from normalize to make mp3gain support ID3 tags. I might attempt this when I have some free time (it could be a while until that happens). Cheers, Richard ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] Patch to support ReplayGain / mp3gain
On 5/8/09 12:14 PM, Frank Blendinger wrote: 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. That script seems to create custom TXXX tags. This is not a standard and it surprises me that players support it. I know rockbox (alternative iPod firmware) does as well. Besides, I don't need to store the data I already have in APE tags in yet another format. This would require me to always run a conversion script after I run mp3gain, and I would have to add the script to abcde (the ripper script I use) as well. 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? Yes, the following TXXX tags: TXXX:replaygain_album_gain TXXX:replaygain_album_peak TXXX:replaygain_track_gain TXXX:replaygain_track_peak 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? The patch I created will favor ReplayGain info found in an APE tag over iTunNORM since RG is a superior algorithm. RVA2 tags are converted to the iTunesDB volume value when --max-vol-adj is used with gnupod_addsong.pl. It is combined with normalization info (if also present) when Sound Check is enabled on the iPod. What will be used if both ID3v2 and APE is present? I read about a (possible?) --ignore-ape option, but I didn't really get what the default behaviour will be. The new default behavior will be to read APE tags, including ReplayGain information. ID3 tags with the same name of APE tags will overwrite the APE tags. ID3v2 tags are favored over ID3v1 tags. Perhaps we should also read TXXX:replaygain_album_gain and TXXX:replaygain_track_gain from ID3v2 tags to replace the respective APE tags. I, for one, would propose to use RVA2 if present and APE only as a fallback, as it is more standardize and also more often present in actual files, APE does not seem to be supported by many (software) players (and I guess not by a single hardware device), while some do support ReplayGain tags in ID3v2. My Neo 35 running OpenNeo reads RG info in APE tags just fine. As do my various Squeezeboxes (powered by SqueezeCenter). One of the problems is that normalization data like RG APE tags and iTunNORM comments is sometimes combined with RVA2 volume information. iTunes is one of the software that does this, and SqueezeCenter also combines the tags (but there is some debate to change that). So favoring RVA2 over RG info should really be selectable by the user. As explained above, iPods will combine the two when both are present in the iTunesDB and Sound Check is enabled. And one last thing: what about support for the music formats covered by the gnupod_convert_* scripts? Those can carry ReplayGain tags, too, so it would be nice to keep/convert them when the audio gets converted. The tags of non-native file formats are spit out by the GET_META part of the gnupod_convert_* scripts. If they spit out the correct soundcheck value, that would work. So if you can show us how to get ReplayGain information from those non-native files, we can probably make it work. So far I only have experience with OGG Vorbis files. There is tool similar to mp3gain called vorbisgain to calculate the gain data and write the tags, and they can be read with the vorbiscomment tool. So I guess it should not be that hard to read those tags as it is done with the common artist/title/... tags and add them to the converted mp3 files. gnupod_convert_OGG.pl uses Ogg::Vorbis::Header which may or may not support the RG tags. If you send me an ogg file (privately) that contains RG info I can check (and patch gnupod_convert_OGG.pl). I have read that there is also support for ReplayGain tags in FLAC files, but I have no experience with that. We'll leave that for someone that actually uses FLAC (I don't). Cheers, Richard ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] DESC field in iTunesDB
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. Personally I see it most used for the show notes of podcasts. Transfering the content to the desc attriute allows you to read those notes while listening to the podcast. I've never used podcasts, but I see how that could be useful. Personally 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. I can use it in smart playlists though. 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). work to get that stuff in there in the first place ;-) I figured as much. I like the way it is done, I just didn't understand why it was there. Info for the mp3 podcasts makes sense. 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. 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 Henrik, On Mon, April 20, 2009 15:32, H. Langos wrote: 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 agree with your reasoning in principle (and will provide a patch for the --noAPEtag option) but if you had ever tried to use iTunes' SoundCheck and compare it against ReplayGain, you wouldn't be proposing this at all. :-) The SoundCheck algorithm is peak based, while ReplayGain uses the RMS energy. The difference between the two is that ReplayGain actually works (makes all tracks sound equally loud) while SoundCheck doesn't. (There is even a commercial product named iVolume that (badly) integrates ReplayGain into iTunes.) For more info see http://replaygain.hydrogenaudio.org/ PS: Please don't take the number of suggestions as an indication of poor quality. Not at all. They are good suggestions. I am a functional programmer before anything else. Now if you told me my code didn't work, I would be hurt. ;-) Besides (after hours of googling for the syntax of the iTunNORM tag) I borrowed most of the code from http://projects.robinbowes.com/flac2mp3/trac/ticket/30 I hope you take it as motivation to continue work on gnupod. If there are things missing or broken I'll definitely work on it some more. Right now, I'm very pleased with gnupod as it does everything I need! I'll send you a new patch when I have some more time. Cheers, Richard ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
