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 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 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
[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
[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
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 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 Ulric
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 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 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 ?
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() {}; 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 MergeGtdbCtx($self->{ctx})});
# Add {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};
+ 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->{$_};
+ }
+}
+
+#
+# Called by doxml if
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() {}; 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 MergeGtdbCtx($self->{ctx})});
# Add {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 un
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] 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] 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) = @_;
Re: [Bug-gnupod] mktunes.pl creates corrupt iTunesDB ?
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. > 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. If it works, I'll probably make a switch for it to mktunes.pl. > 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. After rcs, sccs, cvs and svn git will be the 5th versioning system I'll have to master. :-) 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 13-6-2009 22:36, Richard van den Berg wrote: > 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)? I just had to rule this out, so I got myself a nice and shiny 2nd hand iPod Video 80GB. After converting it to 240GB (needs to load different firmware than the 30GB!) and 23 hours of gnupod sync, I'm pretty sure my issue is RAM related. Before I was able to load 17759 songs in a 25MB iTunesDB. Now (after 2 iterations) I'm up to 22811 songs in a 34MB iTunesDB. However, the full 30415 in a 42MB iTunesDB still does not take. :-( I'll try to contact some other 240GB iPod owners to see how their experience is. I might also try gtkpod (which can't really handle a 3 song collection without stalling for redraws) and maybe iTunes. If it turns out to be a gnupod issue after all, I'll report back here. 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() { $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:
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));
___
Bug-gnupod mailing list
Bug-gnupod@nongnu.org
http
Re: [Bug-gnupod] mktunes.pl creates corrupt iTunesDB ?
On 12-6-2009 15:21, Heinrich Langos wrote: > I'd like to have a chain like this: ok -> ok -> broken > I just compared these files using vbindiff: 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 I can't find anything obviously wrong with the 11184 one (yet). I still have to check if the offsets for the various chunks are 100% correct, but they look ok at a first glance. > 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 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 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. > 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. > 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. > 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! :-) > I guess you add your collection album (directory) wise? So one > gnupod_addsong process for each directory? Yep. I need to because gnupod_addsong does not support different artwork for different albums otherwise. I wrote a wrapper around gnupod_addsong to set the right --artwork and --compilation options automagically. > I suspect that most of the time will still be spent in > GNUpod::XMLhelper::mkfile and GNUpod::XMLhelper::xescaped I think so too. The wait for loading the XML was 30 seconds with 1 files, and grew to 2 minutes with 3 songs after a pod2tunes (create a lot more XML attributes). I'll do the profiling tonight. Thanks for you input. 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 11-6-2009 22:46, Richard van den Berg wrote: > Maybe it doesn't have to do with the iTunesDB size but a limit of the > internal structures? > I do think it is a limitation somewhere in iTunesDB. I tried to add back my 7 smart playlists (I took them out for testing purposes), which make the two largest "ok" iTunesDB "not ok" now: 15892984 not_ok/11403p/iTunesDB 16062708 not_ok/11530p/iTunesDB Cheers, Richard ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
[Bug-gnupod] mktunes.pl creates corrupt iTunesDB ?
I finally built my 240GB iPod. Syncing my 3 mp3s using gnupod took 23 hours to complete. However, when it was all done, my iPod did not show any of the files. It was as if the iTunesDB was not recognized. Cutting the GNUtunesDB.xml down to 100 definitions (and changing nothing else) worked fine after running mktunes.pl. The 100 songs showed up and could be used. So I started the iterative process to find out where the problem was. It tuned out that number 11184 (with id 11210 because I deleted and re-added some incorrectly tagged mp3s) is the issue: When this file is present, the iTunesDB is not recognized. When it is not in the GNUtunesDB.xml, the iTunesDB works fine up until file numer 11531 (id="11558"): The weird thing is, if I put these "broken" files by themself in GNUtunesDB.xml it does work (iPod shows 1 song and plays ok). I'm kind of lost how to fix this, or to predict which files will cause problems. Any ideas anyone? I've saved the GNUtunesDB.xml and iTunesDB during my testing here: http://richard.vdberg.org/gnupod/ The directory names are the number of entries in the GNUtunesDB.xml. The ones in the "ok" top dir work on the iPod, the ones in "not_ok" do not. At first I thought it might be a size limitation of the iTunesDB (around 16 million bytes) but this theory does not really hold: 4744 ok/1/iTunesDB 10759264 ok/07603/iTunesDB 13347604 ok/09503/iTunesDB 14604996 ok/10453/iTunesDB 15229342 ok/10928/iTunesDB 15553196 ok/11166/iTunesDB 15574042 ok/11181/iTunesDB 15575618 ok/11182/iTunesDB 15577038 ok/11183/iTunesDB 15582446 ok/11187/iTunesDB 15876648 ok/11403/iTunesDB 16035782 ok/11522/iTunesDB 16046372 ok/11530/iTunesDB 15577026 not_ok/11183a/iTunesDB 15578438 not_ok/11184/iTunesDB 15583846 not_ok/11188/iTunesDB 15595182 not_ok/11196/iTunesDB 15634814 not_ok/11225/iTunesDB 15715538 not_ok/11285/iTunesDB 15878048 not_ok/11404/iTunesDB 16047658 not_ok/11531/iTunesDB 16047682 not_ok/11531a/iTunesDB 16048968 not_ok/11532/iTunesDB 16051572 not_ok/11534/iTunesDB 16055490 not_ok/11537/iTunesDB 16074306 not_ok/11552/iTunesDB 16112168 not_ok/11581/iTunesDB 16192112 not_ok/11640/iTunesDB 16497676 not_ok/11878/iTunesDB 17123302 not_ok/12354/iTunesDB 18414934 not_ok/13304/iTunesDB 21081010 not_ok/15205/iTunesDB 21082410 not_ok/15206/iTunesDB 42045876 not_ok/30414/iTunesDB 42047276 not_ok/30415/iTunesDB Maybe it doesn't have to do with the iTunesDB size but a limit of the internal structures? I used the unaltered mktunes.pl from CVS (to make sure my title patch did not cause the issue). I have a 5th generation iPod Video. 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 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: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 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 @@
-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.
@@ -954,6 +954,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.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' => [ {
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=2184&r2=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] SoundCheck/ReplayGain
On Tue, May 26, 2009 12:07, H. Langos wrote: > Chris is using the iTunNORM parsing as a workaround. That code has been in > gnupod since 2004. So in theory his approach should work. Ah yes, of course. He is converting the RG info to iTunNORM himself.. which is totally unnecessary with the CVS version of gnupod. :-) Regards, Richard ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] SoundCheck/ReplayGain
Hello Chris, On Mon, May 25, 2009 23:06, chris.com wrote: > - gnupod 0.99.7 Gnupod only supports ReplayGain in the current CVS version (which I believe is labeled as 0.99.8). The 0.99.7 version released on 27 Aug 2008 does not have support for it. > 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. With the CVS version of gnupod this can all be automated. Gnupod can already convert FLAC on the fly to mp3. If you can send me a FLAC file with RG-tag (privately) I can make sure gnupod picks up the ReplayGain value from the FLAC and stores it in the iTunesDB. 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/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. Those options were probably introduced because having iTunNORM comments AND RVA2 tags on one file would have led to very loud results. No, I think they were introduced because the volume fields in the iTunesDB always get applied on the iPod. Without any switches to gnupod, the user would have no control over the volume other than somehow changing the tags in the files. (iTunes has the volume slider per track for this purpose.) Now RVA2/XRVA tags are read instead of iTunNORM comments and we might either get rid of those options or supplement them with --min-db-adj and --max-db-adj to limit the adjustment that goes into the soundcheck attribute. I don't think that's needed. If a user has files with RVA2/XRVA/iTunNORM/ReplayGain tags that do not work for him, he can always disable Sound Check on the iPod and they will all be ignored. Cheers, Richard ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
[Bug-gnupod] Lyrics support
This was just too easy. It's a one line fix that makes lyrics in USLT
mp3 tags work on my iPod 5G.
Cheers,
Richard
Index: src/ext/FileMagic.pm
===
RCS file: /sources/gnupod/gnupod/src/ext/FileMagic.pm,v
retrieving revision 1.86
diff -u -r1.86 FileMagic.pm
--- src/ext/FileMagic.pm22 May 2009 20:52:22 - 1.86
+++ src/ext/FileMagic.pm23 May 2009 12:39:01 -
@@ -537,6 +537,7 @@
$rh{composer} = ($hs->{TCOM} || $hs->{TCM} || "");
$rh{playcount} = int($hs->{PCNT} || $hs->{CNT}) || 0;
$rh{mediatype} = MEDIATYPE_AUDIO;
+ $rh{lyrics_flag}= 1 if($hs->{USLT} || $hs->{ULT});
# RVA2/XRVA trumps all.
if (defined($hs_raw->{RVA2}) or defined($hs_raw->{XRVA})) {
___
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/22/09 11:38 PM, H. Langos wrote: Just commited it all to CVS. Please take a look and see if it does the right thing for your music collection. Great. It works fine with my mp3s (that just contain ReplayGain info in APE tags). Let me know if you find any bugs. I looked over the code and it seems clean to me.. but I didn't test with RVAD / RVA2 tagged files. Cheers, Richard ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
[Bug-gnupod] Append artist to title in iTunesDB
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.pm 6 Oct 2007 07:26:52 - 1.6
+++ src/ext/Mktunes.pm 21 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
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
[Bug-gnupod] gnupod_addsong.pl --artwork without ImageMagick
I just ran into an interesting issue when running "gnupod_addsong.pl --artwork x.jpg *.mp3" on a system without ImageMagick present. The configure script warned me that artwork would not work, but my add shell script used it anyway. The adding of the songs worked (the are in the XML and can be played on the iPod), but for each mp3 gnupod_addsong.pl told me it was skipping the file because it was a duplicate. So strange. The artwork on the iPod showed a black image (no surprise there). $ adddirtoipod . gnupod_addsong.pl Version 0.99.8 -CVS (C) Adrian Ulrich ! [] './Jesse Dee/Bittersweet Batch/Jesse Dee - 01 - Alright.mp3' is a duplicate of song 4676, skipping file ! [] './Jesse Dee/Bittersweet Batch/Jesse Dee - 02 - Around Here.mp3' is a duplicate of song 4677, skipping file ! [] './Jesse Dee/Bittersweet Batch/Jesse Dee - 03 - Slow Down.mp3' is a duplicate of song 4678, skipping file ! [] './Jesse Dee/Bittersweet Batch/Jesse Dee - 04 - Over & Over Again.mp3' is a duplicate of song 4679, skipping file ! [] './Jesse Dee/Bittersweet Batch/Jesse Dee - 05 - My Two Feet.mp3' is a duplicate of song 4680, skipping file ! [] './Jesse Dee/Bittersweet Batch/Jesse Dee - 06 - Remember Me.mp3' is a duplicate of song 4681, skipping file ! [] './Jesse Dee/Bittersweet Batch/Jesse Dee - 07 - Reap What You Sow.mp3' is a duplicate of song 4682, skipping file ! [] './Jesse Dee/Bittersweet Batch/Jesse Dee - 08 - Yet To Come.mp3' is a duplicate of song 4683, skipping file ! [] './Jesse Dee/Bittersweet Batch/Jesse Dee - 09 - New Blades Of Grass.mp3' is a duplicate of song 4684, skipping file ! [] './Jesse Dee/Bittersweet Batch/Jesse Dee - 10 - Still Here.mp3' is a duplicate of song 4685, skipping file ! [] './Jesse Dee/Bittersweet Batch/Jesse Dee - 11 - Alive & Kickin.mp3' is a duplicate of song 4686, skipping file ! [] './Jesse Dee/Bittersweet Batch/Jesse Dee - 12 - Slow Down (Remind).mp3' is a duplicate of song 4687, skipping file > Updating ArtworkDB Done I looked at the code for gnupod_addsong.pl but could not find the cause for this behaviour. Installing ImageMagick of course fixed the issue. Cheers, Richard ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] DESC field in iTunesDB / lyrics display
On 5/10/09 6:00 PM, Richard van den Berg wrote: What do you mean by "all the time"? My iPod shows the artwork during the volume and position display, but not during the rating one. I just checked, and the artwork is also showing during the rating view. The "artwork view" on my iPod shows the artwork fullscreen, and presumably you can browse through multiple artwork images if present in the file (I don't have such files). Cheers, Richard ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] DESC field in iTunesDB / lyrics display
On 5/9/09 5:04 PM, H. Langos wrote: Thats pretty close to what I use (iPod nano (3rd generation)) but since artwork is displayed all the time, there is no separate cycle position for it. What do you mean by "all the time"? My iPod shows the artwork during the volume and position display, but not during the rating one. Are you sure that the postings you've read about lyrics display where talking about your model? Yes. http://forums.macrumors.com/showthread.php?t=160916 suggests that the iPod reads the lyrics from the mp3 and not the iTunesDB. That would explain why my test failed. I only set the lyrics_flag, but did not add a USLT tag. I can confirm that iTunes also adds a USLT tag when you add lyrics to an mp3. I just did another test with 2 files with USLT tags. When the lyrics_flag is 0, no lyrics are shown. When it is 1, the lyrics are shown! So gnupod should really set the lyrics_flag when a USLT is present in mp3 files. This also means that filling the description field with the USLT info for non-podcast mp3s is pretty useless. I don't have enough experience with podcasts to check if the description field or USLT tag is shown for those files. Cheers, Richard ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] Patch to support ReplayGain / mp3gain
On 5/10/09 1:35 AM, H. Langos wrote:
I guess we should go this way:
1. Use RVA2/XRVA or (if the former is missing) REPLAY_GAIN_x to compute a
new "soundcheck" value.
If the first step didn't yield any information:
2. Use iTunNORM's "soundcheck" value and RVA "volume" adjustment.
This would probably work for most people.
Agreed. All we really need to make this happen is a parsing of the RVAD
tag that iTunes creates for the volume adjustment. For the rest I can
write the code myself. ;-)
Do you want to wait until we have a all of the above working before you
commit my current ReplayGain patches to CVS?
I just checked and MP3::Info returns each TXXX tag as an individual
value (not a hash). So TXXX:replaygain_track_gain="-2 dB" becomes
$hs{REPLAYGAIN_TRACK_GAIN}="-2 dB". This means the TXXX tags overwrite
the APE ReplayGain tags by default. I just tested this, and it works;
when ReplayGain data is set differently in the APE tag and TXXX tag, the
TXXX is used by gnupod. Sweet.
Great. Did you check if that works with the parameters that FileMagic.pm uses
for its get_mp3tag() call?
Yes. I tested this with an actual mp3 and the CVS version of gnupod with
my patches applied. It worked without additional modifications.
Cheers,
Richard
___
Bug-gnupod mailing list
Bug-gnupod@nongnu.org
http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] Patch to support ReplayGain / mp3gain
On 5/9/09 6:01 PM, H. Langos wrote: 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. Very good point, I didn't think of that. Quite a shame to limit the RVA2 tag to 6 dB gain only. So I guess we might want to abandon that in favor of manipulating the soundcheck attribute: http://www.id3.org/iTunes_Normalization_settings That should be easy to do. Just convert the Sound Check value to dB, add the RVA value and convert it back. I could write a patch for that, but I'll need some test files as I don't use any RVA tags myself. I guess I can use normalize to create some RVA2 tags. This will imply that gnupod will stop using setting Volume iTunesDB attribute, except when a value is already found in the iTunesDB (by tunes2pod.pl) or am I missing something? 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] 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 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] Patch to support ReplayGain / mp3gain
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
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/8/09 2:26 PM, H. Langos wrote: Could you send me a sample of an iTunes generated RVA2 tag? Sure. I'll fire up iTunes later and send it to you privately. 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 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. 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. If you've got a strong stomach you might want to read the whole thread: http://jwz.livejournal.com/370342.html Great read, thanks. If this is all true, than your patch for gnupod is in vain as the volume of those files was already changed by mp3gain. Reading the APE tag and acting on the information would either double the adjustment or cancel it out, depending on wether mp3gain stores the information on what it did, or how to undo its action. Interesting question. Since I only tag my mp3s, and never let anything change the audio frames, I'm safe no matter what. The following shows others are too. The ReplayGain APE tags always contain the dB change needed to get the volume to the reference level. When mp3gain has altered the file, the RG APE tags will be close(r) to 0. It will also store undo information in the MP3GAIN_UNDO APE tag. $ cp -p org.mp3 cleaned.mp3 $ mp3gain -s d cleaned.mp3 $ mp3gain -s c cleaned.mp3 cleaned.mp3 $ cp -p cleaned.mp3 altered.mp3 $ mp3gain -r altered.mp3 altered.mp3 Applying mp3 gain change of -7 to altered.mp3... $ mp3gain -s c altered.mp3 altered.mp3 Recommended "Track" dB change: 0.035000 Recommended "Track" mp3 gain change: 0 Max PCM sample at current gain: 11529.519104 Max mp3 global gain field: 248 Min mp3 global gain field: 138 $ mp3gain tagged.mp3 tagged.mp3 Recommended "Track" dB change: -10.50 Recommended "Track" mp3 gain change: -7 Max PCM sample at current gain: 38780.534185 Max mp3 global gain field: 255 Min mp3 global gain field: 145 Recommended "Album" dB change for all files: -10.50 Recommended "Album" mp3 gain change for all files: -7 $ cp -p cleaned.mp3 tagged.mp3 $ mp3gain -s c tagged.mp3 tagged.mp3 Recommended "Track" dB change: -10.50 Recommended "Track" mp3 gain change: -7 Max PCM sample at current gain: 38780.534784 Max mp3 global gain field: 255 Min mp3 global gain field: 145 $ cp -p altered.mp3 undo.mp3 $ mp3gain -u undo.mp3 Undoing mp3gain changes (7,7) to undo.mp3... $ mp3gain -s d undo.mp3 $ cmp -l cleaned.mp3 undo.mp3 $ 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/8/09 11:51 AM, H. Langos wrote: 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 agree. It was only until I dug deeper that I realized that code in iTunesDB.pm was really only used in FindHelper.pm. 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: limitval="25" liveupdate="1" matchany="1" moselected="" name="Veere" plid="292683058" > [snip] limitval="25" liveupdate="1" matchany="1" moselected="" name="Random" plid="3323171954" > [snip] 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 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.) Yeah, I was thinking the same thing but I'm afraid the 1% of mp3s that I did not rip/tag myself contain all sorts of tags I don't care about. Maybe I can query my SqueezeCenter MySQL database to see how bad it is. 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/7/09 5:06 PM, H. Langos wrote: Nowerdays I wouldn't let it come anywhere near my iPod. :-) I'm still practicing on my 30GB iPod until I convert it to a 240GB one. After that I guess I won't risk iTunes screwing it up either. It really blows. 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. So I wonder why the author of mp3gain decided to store the information in an ascii APE tags comment instead of using the existing standard. (He definetly was aware of it as he states in the FAQ that he "uses David Robinson's Replay Gain algorithm to calculate how loud the file actually sounds to a human's ears.") mp3gain is one of the first implementations of the Replay Gain algorithm for mp3 files. Please note that the algorithm for calculating the volume adjustment in itself has nothing to do with the way of storing it. I think mp3gain predates the RVAD/RVA2 standards so they went for an APE tag instead. It would have been nicer if they had stuck it in a custom X??? ID3 frame instead. It would have been easier to port it to RVA2 now. I took a look at the source code of normalize and it seems to be able to write to id3v2.3 using XRVA and id3v2.4 using RVA2. Maybe this would be interesting for you too? http://normalize.nongnu.org/ I used normalize for a long time before I switched to mp3gain. Normalize is nice, but the mp3gain algorithm is better. And I like the concept of not altering the data, but just tagging it and only changing the volume during playback. It seems normalize can do that now too. The way I used normalize (before mp3 support was added) was letting it change the volume of the wav files before encoding them to mp3. 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
On 5/7/09 10:09 AM, H. Langos wrote: Did you check when (at which version) MP3::Info gained APE support? I did just now and APE support was added in MP3::Info v1.20, Saturday, January 7, 2006 It would be good to check for this in configure.ac as it already is done for utf8 support. Configure.ac is now checking for v1.01 from 2002. I guess we can just change the UTF8 warning into an APE warning and check for v1.20? Also making sure that older versions don't choke on those extra parameters would be good. (A short look at the code should be enough.) I checked and version 1.13 (10 March 2005) should not have any issues with the additional parameters passed to get_mp3tag(). Are you sure there is always at least one whitespace between the numbers and the "dB" string? When reading the replaygain related web pages I see that most people tend to write stuff like "-12dB" or "6dB". I wouldn't be surprised if some programers followed that example. Or is there some standard definition for this? I was actually thinking the same thing. The space is the way mp3gain does it, but it is not very common to use a space, no. Since mp3gain is the de facto software to use for calculating ReplayGain it doesn't really matter though. We can change the \s+ to \s* for completeness sake. The \s+ was in the code I borrowed, and I just didn't touch it. BTW: While you're at it ... have you ever seen RVA / RVA2 / XRVA tags in the wild? I tag 99% of my own files, but I did see RVA2 tags on some iTunes mangled files, yes. Note that iTunes uses iTunNORM for Sound Check and RVA2 for that volume slider thingie. I read a post of someone who volume leveled his whole collection using that slider.. yikes. I so prefer mp3gain. :-) Richard ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
[Bug-gnupod] DESC field in iTunesDB
When I first started ripping all my CDs I made the decision that the ID3
genre field was too limiting, so I split my collection into different
directories named after genres and/or source of the CDs
(wife/brother/daughter). I have generated several m3u playlists using
these directory names. Now that I switched to the iPod, this information
is no longer available to me. So I started to look for a field in the
iTunesDB that I could use for that purpose. The FDESC and DESC fields
fit rather nicely. FDESC has a width of 15 characters which is enough
for me today, but could be limiting in the future. So I patched
FileMagic.pm to place the full pathname of the mp3 into the DESC field.
I realize that this is a patch for personal purposes, but looking at
what the DESC field is used for now I wonder if it has a real purpose:
rh{desc} = __merge_strings({joinby => " ", wspace => "norm", case
=> "ignore"},($hs->{USLT} || $hs->{ULT}),($nonitunescomment ||
$h->{COMMENT}));
It joins the USLT or ULT field (which are used for lyrics) with the
$nonitunescomment (which is the ID3v2 COMM field with the iTun* fields
stripped) or ID3v1 comment. The comments are already stored in the
iTunesDB in the COMMENT field. Storing lyrics doesn't seem to make much
sense since the field is only 40 characters wide.
Maybe my patch is not so bad to be applied for everyone? (If so, the
nonitunescomment code can also be discarded.)
Regards,
Richard
--- FileMagic.pm.org2009-04-25 14:43:31.0 +0200
+++ FileMagic.pm2009-04-29 16:49:38.0 +0200
@@ -23,6 +23,7 @@
use strict;
use Unicode::String;
use MP3::Info qw(:all);
+use File::Spec;
use GNUpod::FooBar;
use GNUpod::QTfile;
@@ -516,7 +517,7 @@
$rh{artist} = ($hs->{TPE1} || $hs->{TP1} || $hs->{TPE2} ||
$hs->{TP2} || $h->{ARTIST} || "Unknown Artist");
$rh{genre} = _get_genre($hs->{TCON} || $hs->{TCO} || $h->{GENRE}
|| "");
$rh{comment}= ($hs->{COMM} || $hs->{COM} || $h->{COMMENT} || "");
- $rh{desc} = __merge_strings({joinby => " ", wspace => "norm",
case => "ignore"},($hs->{USLT} || $hs->{ULT}),($nonitunescomment ||
$h->{COMMENT}));
+ $rh{desc} = File::Spec->rel2abs($file);
$rh{composer} = ($hs->{TCOM} || $hs->{TCM} || "");
$rh{playcount} = int($hs->{PCNT} || $hs->{CNT}) || 0;
if($hs->{REPLAYGAIN_TRACK_GAIN} ne "") {
___
Bug-gnupod mailing list
Bug-gnupod@nongnu.org
http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] Patch to support ReplayGain / mp3gain
Hello Henrik,
I finally found some time to make a proper patch for the ReplayGain
support. Let me know if this is acceptable, or if it needs some more
tweaking. I've added the following options to gnupod_addsong.pl:
--disable-apeDo not read APE Tags (MP3 Only)
--disable-v1 with --disable-v2 implies --disable-ape
--replaygain-album Use the ReplayGain album value instead of
the ReplayGain track value (default)
On 4/20/09 3:32 PM, H. Langos wrote:
- 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. So the first
and easier to understand version should be ok.
Actually, if the ReplayGain value is anything above 33.01 dB
_parse_ReplayGain() will return 0. It's not very likely, but possible.
So I went with the second form which seems to work well.
Cheers,
Richard
? .gnupod_version
? Makefile
? autom4te.cache
? config.log
? config.status
? configure
? src/ext/FileMagic.pm.org
Index: src/gnupod_addsong.pl
===
RCS file: /sources/gnupod/gnupod/src/gnupod_addsong.pl,v
retrieving revision 1.104
diff -u -r1.104 gnupod_addsong.pl
--- src/gnupod_addsong.pl 25 Mar 2009 13:43:27 - 1.104
+++ src/gnupod_addsong.pl 6 May 2009 10:17:49 -
@@ -44,14 +44,14 @@
$opts{mount} = $ENV{IPOD_MOUNTPOINT};
#Don't add xml and itunes opts.. we *NEED* the mount opt to be set..
GetOptions(\%opts, "version", "help|h", "mount|m=s", "decode|x=s",
"restore|r", "duplicate|d", "disable-v2", "disable-v1",
- "set-title|t=s", "set-artist|a=s", "set-album|l=s",
"set-genre|g=s", "set-rating=i", "set-playcount=i",
- "set-bookmarkable|b", "set-shuffleskip", "artwork=s",
+ "disable-ape", "set-title|t=s", "set-artist|a=s",
"set-album|l=s", "set-genre|g=s", "set-rating=i",
+ "set-playcount=i", "set-bookmarkable|b", "set-shuffleskip",
"artwork=s", "replaygain-album",
"set-songnum", "playlist|p=s@", "reencode|e=i",
"min-vol-adj=i", "max-vol-adj=i", "playlist-is-podcast",
"podcast-files-limit=i", "podcast-cache-dir=s",
"podcast-artwork", "set-compilation");
-GNUpod::FooBar::GetConfig(\%opts, {'decode'=>'s', mount=>'s', duplicate=>'b',
model=>'s',
- 'disable-v1'=>'b', 'disable-v2'=>'b',
'set-songnum'=>'b',
+GNUpod::FooBar::GetConfig(\%opts, {'decode'=>'s', mount=>'s', duplicate=>'b',
model=>'s', 'replaygain-album'=>'b',
+ 'disable-v1'=>'b', 'disable-v2'=>'b',
'disable-ape'=>'b', 'set-songnum'=>'b',
'min-vol-adj'=>'i', 'max-vol-adj'=>'i',
'automktunes'=>'b',
'podcast-files-limit'=>'i',
'podcast-cache-dir'=>'s', 'podcast-artwork'=>'b' },
"gnupod_addsong");
@@ -157,6 +157,8 @@
#Get the filetype
my ($fh,$media_h,$converter) =
GNUpod::FileMagic::wtf_is($file, {noIDv1=>$opts{'disable-v1'},
noIDv2=>$opts{'disable-v2'},
+
noAPE=>$opts{'disable-ape'},
+
rgalbum=>$opts{'replaygain-album'},
decode=>$opts{'decode'}},$con);
unless($fh) {
@@ -734,6 +736,8 @@
0 = download all (default), -X = download
X oldest items, X = download X newest items
--disable-v1 Do not read ID3v1 Tags (MP3 Only)
--disable-v2 Do not read ID3v2 Tags (MP3 Only)
+ --disable-apeDo not read APE Tags (MP3 Only)
--disable-v1 with --disable-v2 implies --disable-ape
+ --replaygain-album Use the ReplayGain album value instead of
the ReplayGain track value (default)
-x --decode=pcm|mp3|aac|aacbm Convert FLAC Files to WAVE/MP3 or AAC
'on-the-fly'. Use '-e' to specify a quality/bitrate
-x --decode=video Convert .avi Files into iPod video
'on-the-fly' (needs ffmpeg with AAC support)
-x --decode=alacConvert FLAC Files into Apple Lossless
'on-the-fly' (needs ffmp
Re: [Bug-gnupod] Patch to support ReplayGain / mp3gain
Hi Henrik, On Mon, April 20, 2009 17:47, H. Langos wrote: > I hope the iPod does take care of clipping issues. (Or aren't there any?) In theory there could be clipping, but for 99% of the current pop music releases the volume will be lowered. And even for those (older) releases where the volume will be increased, peaks will rarely go beyond full scale. Only for music with a wide dynamic range such as classical clipping could become a real issue. > Ever encountered any problems there? Nope. I did see some clipping warnings while running mp3gain, but I never heard any issues. At home I use SqueezeCenter which I expect to implement the solution explained here: http://replaygain.hydrogenaudio.org/player_clipping.html I've only been using the iPod for about a week, but didn't hear any problems so far. > Nice summary there. You could add that link to the documentation of > _parse_ReplayGain(). :-) Yes, I will. Giving credit is the least I can do for stealing the code. :-) > But if you were only after the iTunNORM syntax, > you might have saved yourself some google time... [snip] >http://www.id3.org/iTunes_Normalization_settings Actually, I did stumble upon the slimdevices.com page that information was taken from. From there it only took a few minutes to find the flac2mp3 perl code. Only after I turned it into a full ReplayGain to SoundCheck script I found out that writing the iTunNORM tags does not help with iTunes 8. You need to write to the iTunesDB. Googling some more for the iTunesDB binary format I found gtkpod which says it had adapted it's C code from gnupod. :-) 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
[Bug-gnupod] gnupod_INIT does not read ~/.gnupodrc
I just found that gnupod_INIT does not read ~/.gnupodrc for the iPod mount point. No biggie, just wanted to let you know. Regards, Richard ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
[Bug-gnupod] Patch to support ReplayGain / mp3gain
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. :-)
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 patch is against the current CVS version. 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.
Regards,
Richard
*** FileMagic.pm.orig 2009-04-17 22:46:54.0 +0200
--- FileMagic.pm2009-04-17 22:51:25.0 +0200
***
*** 483,489
$rh{fdesc}= "MPEG ${$h}{VERSION} layer ${$h}{LAYER} file";
$h = MP3::Info::get_mp3tag($file,1)unless $flags->{'noIDv1'};
#Get the IDv1 tag
! $hs = MP3::Info::get_mp3tag($file,2,2) unless $flags->{'noIDv2'};
#Get the IDv2 tag
my $nonitunescomment = undef;
#The IDv2 Hashref may return arrays.. kill them :)
--- 483,489
$rh{fdesc}= "MPEG ${$h}{VERSION} layer ${$h}{LAYER} file";
$h = MP3::Info::get_mp3tag($file,1)unless $flags->{'noIDv1'};
#Get the IDv1 tag
! $hs = MP3::Info::get_mp3tag($file,2,2,1) unless $flags->{'noIDv2'};
#Get the APE + IDv2 tag
my $nonitunescomment = undef;
#The IDv2 Hashref may return arrays.. kill them :)
***
*** 519,525
$rh{desc} = __merge_strings({joinby => " ", wspace => "norm",
case => "ignore"},($hs->{USLT} || $hs->{ULT}),($nonitunescomment ||
$h->{COMMENT}));
$rh{composer} = ($hs->{TCOM} || $hs->{TCM} || "");
$rh{playcount} = int($hs->{PCNT} || $hs->{CNT}) || 0;
! $rh{soundcheck} = _parse_iTunNORM($hs->{COMM} || $hs->{COM} ||
$h->{COMMENT});
$rh{mediatype} = MEDIATYPE_AUDIO;
# Handle volume adjustment information
--- 519,529
$rh{desc} = __merge_strings({joinby => " ", wspace => "norm",
case => "ignore"},($hs->{USLT} || $hs->{ULT}),($nonitunescomment ||
$h->{COMMENT}));
$rh{composer} = ($hs->{TCOM} || $hs->{TCM} || "");
$rh{playcount} = int($hs->{PCNT} || $hs->{CNT}) || 0;
! if($hs->{REPLAYGAIN_TRACK_GAIN} ne "") {
! $rh{soundcheck} =
convertReplayGainToSoundCheck($hs->{REPLAYGAIN_TRACK_GAIN});
! } else {
! $rh{soundcheck} = _parse_iTunNORM($hs->{COMM} || $hs->{COM} ||
$h->{COMMENT});
! }
$rh{mediatype} = MEDIATYPE_AUDIO;
# Handle volume adjustment information
***
*** 789,794
--- 793,821
=cut
+ #
+ # Convert ReplayGain to SoundCheck
+ sub convertReplayGainToSoundCheck {
+ my ($gain) = @_;
+ if ( $gain =~ /(.*)\s+dB$/ ) {
+ $gain = $1;
+ }
+ my $result = round((10 ** (-$gain / 10)) * 1000);
+
+ if ($result > 65534) {
+ $result = 65534;
+ }
+
+ return oct(sprintf("0x%08X",$result));
+ }
+
+ #
+ # Round to next integer
+ sub round {
+ my $number = shift;
+ return int($number + .5 * ($number <=> 0));
+ }
+
1;
___
Bug-gnupod mailing list
Bug-gnupod@nongnu.org
http://lists.nongnu.org/mailman/listinfo/bug-gnupod
