also Length is unknown to amarok

Bitrate is "?"

Tag reading in amaroK is handled by TagLib. I'm reassigning the report.

update: amarok 1.1:

title is now filename without file-extension

all other fields are empty, bitrate is "?"

amarok 1.2-cvs (todays HEAD) 
taglib 1.3

tagging for m4a still not working

*** Bug 79833 has been marked as a duplicate of this bug. ***

without tagging m4a, they are also not taken to the amarok collection-db :-(

Concerning comment #6: The following patch allows me to add .ape/.m4a files to the collection browser. Still no tags though.

--- src/collectionreader.cpp    11 Dec 2004 11:59:50 -0000      1.2
+++ src/collectionreader.cpp    24 Dec 2004 01:38:26 -0000
@@ -198,7 +198,7 @@

     QStringList validImages, validMusic;
     validImages << "jpg" << "png" << "gif" << "jpeg";
-    validMusic  << "mp3" << "ogg" << "wav" << "flac";
+    validMusic  << "mp3" << "ogg" << "wav" << "flac" << "ape" << "m4a";

     for ( uint i = 0; i < entries.count(); i++ )
     {


As for m4a tag reading.. gstreamer's qtdemux plugin has tag reading code for m4a files, which might be useful as a reference:

http://cvs.freedesktop.org/gstreamer/gst-plugins/gst/qtdemux/qtdemux.c?rev=1.70&view=markup

Or have TagLib use the gstreamer framework (if present) to read the tags? Another reference (rhythmbox gstreamer tag code):

http://cvs.gnome.org/viewcvs/rhythmbox/metadata/rb-metadata-gst.c?rev=1.35&view=auto

I am considering implementing it in an external taglib-compatible extension. The reason to make it external is to be able to depend on libmp4. I need to interact with the same library when writing the aKode-plugin so I might write a taglib extension at the same time.

Created attachment 10820 [details]
Patch for MP4 and WMA support to taglib 1.3.1
bz2 diff

on comment #9 :

the patch i cannot download. the browser thinks that it is text/plain but it seems to be a binary format (no plain text). what format is it in? can you edit the mime-type of the attachement of this bug? thank you

the patch is a compressed bzip2 patch.

Sorry not familiar with bugzilla so did notice the mime type.

On compile I get the following:

mp4properties.cpp: In member function `void TagLib::MP4::Properties::readAudioTrackProperties(void*, MP4TrackId)':
mp4properties.cpp:99: error: `UINT64_TO_DOUBLE' undeclared (first use this function)
mp4properties.cpp:99: error: (Each undeclared identifier is reported only once for each function it appears in.)

Where is this defined?

*** Bug 102761 has been marked as a duplicate of this bug. ***

*** Bug 97220 has been marked as a duplicate of this bug. ***

The patch in comment #9 seems to work for me (on Gentoo) provided that I add the line

#define UINT64_TO_DOUBLE(a) ((double)((int64_t)(a)))

in mp4properties.cpp.  Although I haven't investigated extensively, the need for this line seems to be related to the fact that I have installed "faad2" rather than "mpeg4ip" -- when I had mpeg4ip instead I was able to compile the patched taglib without any modifications.

When I say "the patch works" I mean that after applying this patch to taglib, amarok is able to read tags on .m4a files and add them to the "Collection".  I haven't done any other testing.

the patch from #9 could be cleaned up, it contains a lot of unneeded changes to generated files (i.e. apidocs) and lines that weren't really changed (-Bbw missing in diff options). Maybe that would make it easier to integrate aac-tag support.

I should warn that the patch may not be free of side effects.  On my system, I've been encountering a nasty bug lately where _writing_ of mp3 tags is broken some of the time.  A symptom is that the "Genre" tag gets set to "Blues Blues Blues Blues Blues Blues Blues" while the "Artist" and "Author" tags are left blank.  Reverting this patch seems to make the problem go away -- although since the problem is a bit intermittent, it is hard to be 100% sure that the patch was really the cause.

I experienced that the patched taglib is unable tor read/write any not-ascii chars and also messes up some ascii-only tags

I observe the same behavior than described in comment #18, tag edition with non-ascii characters is broken.

Created attachment 11422 [details]
pared-down patch including MP4 tag support only

Here is a much-reduced version of the patch, with references to generated files
cut out, as well as the WMA related stuff, so all that's left is the source
changes needed for M4A support.  This patch works for me without the annoying
side effect I described above, although I can't claim to understand why that
problem was occurring.

make[3]: *** [taglib_mp4file.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
In file included from taglib_mp4file.h:26,
                 from mp4tag.h:25,
                 from mp4tag.cpp:24:
mp4properties.h:27:17: mp4.h: No such file or directory
In file included from taglib_mp4file.h:26,
                 from mp4tag.h:25,
                 from mp4tag.cpp:24:
mp4properties.h:60: error: `MP4FileHandle' has not been declared
mp4properties.h:60: error: ISO C++ forbids declaration of `mp4File' with no type
mp4properties.h:64: error: `MP4FileHandle' has not been declared
mp4properties.h:64: error: `MP4TrackId' has not been declared
mp4properties.h:64: error: ISO C++ forbids declaration of `mp4File' with no type
mp4properties.h:64: error: ISO C++ forbids declaration of `trackId' with no type

I suspect that the compile problem occurs because you haven't installed the AAC decoder (either "faad2" or "mpeg4ip") -- on my system, /usr/include/mp4.h is provided by "faad2".

I guess the experts will know what is the best way to deal with this extra dependency; e.g. comment #8 seemed to indicate that one might ultimately want to add m4a functionality in an extension, for just this reason.  But for those who just want a hack to make it work today, this patch seems to work pretty well.

(See also comment #12, comment #15 if you get an error later in the compile.)

The patch from comment #20 worked for me with the change in mp4properties.cpp from comment #15 - using faad2 as the mp4 library. 
Only glitch is with the character encoding - my system runs utf8, but my music files are tagged in iso8859-1... Amarok seems to auto-detect this for mp3 files, but the aac files show up with "broken" characters. 

Also, tag writing still works for mp3 files, but not for aac (which is to be expected, i suppose).

Installing mpeg4ip fixes my compile error from comment #21. Amarok now reads the metadata and adds aac files to my library. Now we just need tag editing :) Right now, it can be done from the command line using mp4tags from the mpeg4ip package.

With the patch, taglib doesn't seem to be able to read the "Genre" tag from my m4a files. 

Actually, it works if you have the most current mpeg4ip package -> 1.3. I had taglib compiled against mpeg4ip-1.1, and my "Genre" tags weren't being read correctly.

Created attachment 11992 [details]
taglib-1.4 aacpatch

Stefan Gehn's Patch from comment #16, modified for taglib-1.4. I added nothing,
only changed so the patch would compile with taglib-1.4. Works for me with
taglib-1.4, and amarok displays AAC information on mp4 files.

I'm having problems compiling taglib-1.4 with this patch. For some reason it's having trouble finding the taglib/mp4/taglib_mp4.h file, even though it was in fact created in that location as specified by the patch.

fileref.cpp:30:28: taglib_mp4file.h: No such file or directory
fileref.cpp: In static member function `static TagLib::File* TagLib::FileRef::create(const char*, bool, TagLib::AudioProperties::ReadStyle)':
fileref.cpp:176: error: `MP4' has not been declared
fileref.cpp:176: error: cannot allocate an object of type `TagLib::File'
fileref.cpp:176: error:   because the following virtual functions are abstract:
../taglib/toolkit/tfile.h:84: error:  virtual bool TagLib::File::save()
../taglib/toolkit/tfile.h:78: error:  virtual TagLib::AudioProperties* TagLib::File::audioProperties() const
../taglib/toolkit/tfile.h:71: error:  virtual TagLib::Tag* TagLib::File::tag() const

Right, well, I sorted the include problem. In taglib/Makefile.in, add:
	-I$(top_srcdir)/taglib/mp4 \
around line 259. Now, however, there's an "undefined reference" error that I don't know what to do about:
.libs/fileref.o(.text+0xa94): In function `TagLib::FileRef::create(char const*, bool, TagLib::AudioProperties::ReadStyle)':
: undefined reference to `TagLib::MP4::File::File(char const*, bool, TagLib::AudioProperties::ReadStyle)'
collect2: ld returned 1 exit status

Has anyone actually used this patch successfully?

Having the exact same problem as in Comment #29 - using mpeg4ip version 1.3, and TagLib 1.4. Strangely, if I go back to TagLib 1.3.1 and apply the relevant patch, I don't get the first error (fileref.cpp:30:28: taglib_mp4file.h: No such file or directory) but soon afterwards I get the error in Comment #28. Where should TagLib::MP4::File::File be defined?

so is this working yet? will it be merged into taglib anytime soon? Amarok users are craving this!

This patch works perfectly for me ! Taglib 1.4 + faad2 2.0 (and NO mpeg4ip) + the patch from comment #27 + the correction from comment #15 gives a perfectly working taglib, which can read AAC/M4A tags; Amarok can now add all my m4a files to the collection, and read their tags.

No, this won't be merged for several reasons:

- TagLib doesn't use external libraries, which the patch does
- Just grabbing the code from that library and using it in TagLib also isn't an option (well, really it's not anyway since it's C, but...) since said library is GPL'ed rather than LGPL'ed.
- It doesn't currently support writing tags as all other formats do

However application authors may still choose to use this class; it doesn't need to be merged into TagLib to be used.

I am using taglib 1.4 and faad2 2.0. with GCC 3.3.5. In order to get the patched taglib (see comment #32) to compile, I had to modify "void MP4::Tag::readTags( MP4FileHandle mp4file )"  by replacing "uint16_t numvalue, numvalue2;" with "u_int16_t numvalue, numvalue2;"

After some serious experimenting, learning and searching on the internet I managed to compile taglib 1.4 with the aac patch.

I consider this a remarkable feat considering that I am a relative linux newbie and have hardly compiled anything since assebler on the Z80 was all the rage.  Besides senility is starting to kick in.

Unfortunately though, the patch only works for me if the file extension is .mp4 not .m4a or .aac - same files.

Any ideas how I might fix that

I've successfully applied the patch from comment #27 and the correction from comment #15 and taglib 1.4 compiles successfully. However, when I run amarok it crashes upon creating the collection. I'm using faad2 v2.0, GCC 4.0.1, and amaroK 1.3 with the xine engine. Any suggestions? Is m4a support going to make it into an official release?

Like Chris in comment #36 I find the patch from comment #27 integrates with taglib 1.4 and compiles fine, but Amarok then crashes when it sees a m4a file. This can either be a collection scan or drag/dropping such a file onto Amarok.

I have gcc version 3.4.3 on a 64 bit Gentoo installation using Amarok 1.3.1 with the Gstreamer engine and faad 2.0-r7.

Is there a command line front end to taglib that would let me debug this? 

Created attachment 12626 [details]
Revised patch to taglib to read m4a tag data

Here is a revised version of patch from comment #27 including the correction
from comment #15 and a further modifications to get rid of the crashes I was
getting from Amarok.

I used the tagreader example to debug the crashes, and found that taglib called
 a function MP4Read from faad2, which returned an error condition on some m4a
files. When this happened code in added to taglib from the comment #27 patch
then went on to pass a NULL pointer to delete which caused the crash. This
patch handles the error more gracefully, and Amarok gets empty tag data for the
erroring files.

I tried to compile taglib with the patch from comment 38 and I had multiple pbms.

I had to replace
#include "taglib_mp4file.h" by 
#include "mp4/taglib_mp4file.h" in fileref.cpp
because it could not find this file.

I use  faad2-2.1-0.20050201.2plf, libfaad2_0-static-devel-2.1-0.20050201.2plf, libfaad2_0-2.1-0.20050201.2plf, libfaad2_0-devel-2.1-0.20050201.2plf
but there was no  /usr/include/mp4.h .But I have /usr/include/mp4ff.h
I tried to replace all occurrences of mp4.h by mp4ff.h

And I eventually ran into the following error:
mp4/mp4properties.h:60: error: 'MP4FileHandle' has not been declared
mp4/mp4properties.h:64: error: 'MP4FileHandle' has not been declared
mp4/mp4properties.h:64: error: 'MP4TrackId' has not been declared
mp4/mp4tag.h:42: error: 'MP4FileHandle' has not been declared
mp4/taglib_mp4file.h:84: error: 'MP4FileHandle' does not name a type
make[3]: *** [fileref.lo] Error 1

indicating I must have done something wrong. I am not sure I know what I am doing but it does not work for me.

I am using faad2 version 2.0, and since /usr/include/mp4.h comes from there I suspect using faad2 version 2.1 is the cause of your difficulties.

mp4.h is in libmp4-dev.

in applying #38 patch

make[3]: Entering directory `/DataDrive/Files/Tarballz/TagLib/taglib-1.4/taglib'
/bin/sh ../libtool --silent --mode=link --tag=CXX g++  -Wnon-virtual-dtor -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -Wno-non-virtual-dtor -O2 -Wformat-security -Wmissing-format-attribute -fno-exceptions -fno-check-new -fno-common    -o libtag.la -rpath /usr/local/lib  -no-undefined -Wl,--no-undefined -Wl,--allow-shlib-undefined -version-info 5:0:4 tag.lo fileref.lo audioproperties.lo ./mpeg/libmpeg.la ./ogg/libogg.la ./flac/libflac.la ./mpc/libmpc.la ./ape/libape.la ./toolkit/libtoolkit.la
.libs/fileref.o: In function `TagLib::FileRef::create(char const*, bool, TagLib::AudioProperties::ReadStyle)':
fileref.cpp:(.text+0xa3b): undefined reference to `TagLib::MP4::File::File(char const*, bool, TagLib::AudioProperties::ReadStyle)'
collect2: ld returned 1 exit status
make[3]: *** [libtag.la] Error 1

I got it compiled but amarok just freezes when i try and load up m4a files.

Well, m4a support is now in amaroK. So Scott feel free to close the wish if you want.

It is? I was unable to add m4as to my collection without this patch

When was the support added to Amarok?  Does this mean that Amarok no longer depends on taglib?  Is tag editing now supported?  Do I need to get the CVS HEAD version of Amarok or some other version?  Is the new functionality in the current stable release?  I currently have 1.3.1 installed and, although I can play m4a files, I am unable to make changes to tags (I have my m4a files on a FAT32 partition).

Support was apparently added about 6 hours ago.  ;-)

It's using the previously mentioned read-only patches.  Those aren't suitable for integration into TagLib (for the reasons in comment #33), but there are mechanisms within TagLib for adding support for additional file formats in cases like this.

This is a wishlist item, so I'm fine leaving it open for the moment.  If someday specs for the format appear this may get implemented in TagLib itself.  I don't know what the chances of that happening are, but well, that's not up to me.

Okay, do you know whether read/write of the tags is supported?
Also, I looked, but didn't find how to get the CVS HEAD version
of amarok.  Does this mean that I won't need to patch taglib
to get m4a tags working in amarok?  Thanks!

Okay, I installed subversion, downloaded the latest amarok source, built and installed it.  With your very latest taglib source from CVS (unpatched), I get no tag support for m4a in amarok (unless I am messing up my build process, somehow).
I will try adding the patches to taglib again.  :-(  

I don't know -- I don't use amaroK or these file types; I just read the CVS commit and looked at a little of the code that's supposed to make those types work in amaroK.  You'll have to ask the amaroK developers for more information.

You have to run configure --with-mp4v2

I can't get it to compile, myself, though. It fails looking for systems.h, which my distro (Mandriva) doesn't have in any of its current packages, and faad2 throws all kinds of compile errors.

Well, systems.h doesn't seem to be included in either mpeg4ip or faad2 CVS, so i just commented out the include on line 30 of amarok/src/metadata/mp4/mp4properties.cpp and, lo and behold, it works like a charm. I can read and edit mp4 tags and add the files to my collection; beautiful!

Okay, I managed to finally get everything built as Michael did.  I can confirm that it works for me.  I certainly hope the distributions pick up the patch from comment #38 and ship with it.  

As you mentioned, Scott, it would be nice to keep this wishlist item in case an acceptable solution arises for you to encorporate this functionality into your source tree.  BTW, you need to update your Taglib page to reflect that fact that anonymous CVS is no longer available for KDE.  subversion must be used instead.

Thanks!

I think you missed the point Miles -- this wasn't a change in TagLib and the patch isn't required for the current amaroK.  TagLib has a system for adding in additional format support without patching the sources and they've started using that in the current amaroK source.

And yes -- I'll switch the instructions from CVS to SVN shortly.

downloaded amarok from SVN and compiled. its currently updating my collection, but I've got my personal CD's in mp4 and I'm going over 802.11g so its gunna take a while but so far the CollectionDB is showing that it can read my mp4's!

I'm using the TagLib package from Debian as well, just compile Amarok from SVN!

All my mp4's got loaded but I have a lot of tracks where when I try and play it takes forever(like 10's of minutes) to populate the playlist and then I usually get an error about the track not being able to play. Some tracks do play though.


this is all over an NFS mount, but I've never had an issue with it before and I often transfer large files so I don't think its an issue.

Ok, going all caps here so that hopefully people scanning this will see it:

I DO NOT USE OR MAINTAIN AMAROK.  PLEASE, PLEASE, IF YOU'RE HAVING FURTHER PROBLEMS WITH AMAROK, OR ISSUES RELATED TO AMAROK, OR ISSUES RELATED TO THE CURRENT AMAROK MEANS OF READING THESE FILES REPORT THEM TO THE AMAROK DEVELOPERS.

ALSO NOTE THAT THE BUG TRACKING SYSTEM IS NOT A DISCUSSION BOARD.  PLEASE TRY TO KEEP ISSUES HERE ISOLATED TO ISSUES WITH TAGLIB.

To clarify its my understanding that when amaroK is built with libmp4v2 (as opposed to FAAC) m4a tag writing does work fine. Doesn't make any difference for taglib since its still an external library...

Sorry for starting off all the spam Scott.

Lots of people filing invalid bugs in Amarok,

http://bugs.kde.org/show_bug.cgi?id=134660
http://bugs.kde.org/show_bug.cgi?id=122172
http://bugs.kde.org/show_bug.cgi?id=134271

It seems like writing to m4a tags is corrupt under some circumstances, but it's difficult for the casual user like me to see whether that is a bug in taglib, a Library it depends on, or some other dependency of Amarok. 

I looked through the libmp4v2 source files, and they all appear to be under MPL 1.1, not GPL, as previously stated.

This was already implemented in SVN.