Summary: | Not possible to copy WAVs to an iPod | ||
---|---|---|---|
Product: | [Applications] amarok | Reporter: | Isaac Wilcox <iwilcox> |
Component: | Collections/iPod iPhone | Assignee: | Amarok Developers <amarok-bugs-dist> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | matej |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Isaac Wilcox
2006-07-20 21:16:31 UTC
Hm, I don't really know what to do about that: currently, Amarok assumes that transferring the file failed because reading the transferred file's metadata using the usual mechanism failed. In this case this is because of the fact that wavs don't carry any metadata and thus taglib cannot read it. Solving this is not easy as Amarok would at least need to know the play length for adding it correctly. And we would need some extra code for dealing with that. > the fact that wavs don't carry any metadata That's what I thought, but I wasn't certain, so I had a quick dig. Firstly, there's one way that sounds fairly non-standard and crap: http://mail.kde.org/pipermail/taglib-devel/2005-August/000186.html Secondly, MediaMonkey (Windows-only I think; you probably know better than me) appears to support it somehow; on page http://www.mediamonkey.com/product.htm it says "Tag music with a simple yet powerful interface using industry-standard formats. MediaMonkey includes [...] a WAV tag editor". http://www.mediamonkey.com/product.htm Some discussion on their forums around the time this got implemented, but giving no clue of the underlying method: http://www.mediamonkey.com/forum/viewtopic.php?t=5213 And finally (and most promisingly) something called "Tigotago" claims to support it, and when asked on the forums how they do this, someone pointed at an almost RFC-like document on embedding info into WAVs, which might be the nearest thing to a standard: http://www.tigotago.com/forum/viewtopic.php?pid=133 Now, all of this is a fairly moot point, because tagged WAVs in the wild are likely very rare creatures, so amaroK would have to be able to work in the no-tag case as you say. Maybe the library/bit of code that is failing could just be changed to succeed and provide empty tags? Or maybe fabricate a track name from the filename. That would at least circumvent the error I'm getting, right? > Amarok would at least need to know the play length for adding it correctly. Why? Is there some required field in the iTunesDB or something? Regardless, the code could probably be borrowed from gnupod if needed, because as I said, adding the WAV with that worked fine. More on that moot point: Actually, the "fairly non-standard and crap" might not be crap, and might even be a de facto standard; reading around, it seems some tag editors and players support embedding an ID3 tag into a RIFF chunk - at least they don't just tack it on the end. The chunk's 4-letter code is "ID3 " (with the space). iTunes tags WAVs this way, apparently. There's also a format called "BWF" that does a very similar trick. The other tagging method uses just standard RIFF chunks, but the tags are fixed and very limited compared to ID3. There are some examples of tagged WAVs (with both standard RIFF chunks and embedded ID3 chunks) in this zip: http://www.unzerpum.net/temp/WavTags.zip (found this when I followed a link from the MediaMonkey forum: http://www.mediamonkey.com/forum/viewtopic.php?p=52094&sid=9b71e863d7c71539fcb53f94d585c994 ) You can peer inside them a little bit with "showriff", but that just shows the structure, not the tag content. I'll leave moot point alone now, as it's off-topic in this bug, but I'm tempted to raise a new bug titled "amaroK(/TagLib) should support tagged WAVs" :) SVN commit 598180 by aumuell: allow for transferring .wav files to ipods BUG: 131130 M +1 -0 ChangeLog M +1 -1 src/mediabrowser.cpp M +6 -1 src/mediadevice/ipod/ipodmediadevice.cpp --- trunk/extragear/multimedia/amarok/ChangeLog #598179:598180 @@ -5,6 +5,7 @@ VERSION 1.4.4 FEATURES: + * Transfer .wav-files to iPods. (BR 131130) * Xine and Helix engines now support three different crossfading modes: always, on manual track changes only, or on automatic track changes only. --- trunk/extragear/multimedia/amarok/src/mediabrowser.cpp #598179:598180 @@ -2423,7 +2423,7 @@ else { MetaBundle bundle2(dst); - if(!bundle2.isValidMedia()) + if(!bundle2.isValidMedia() && bundle2.filesize()==MetaBundle::Undetermined) { tryToRemove = true; // probably s.th. went wrong --- trunk/extragear/multimedia/amarok/src/mediadevice/ipod/ipodmediadevice.cpp #598179:598180 @@ -293,10 +293,15 @@ track->ipod_path = g_strdup( ipodPath(pathname).latin1() ); debug() << "on iPod: " << track->ipod_path << ", podcast=" << podcastInfo << endl; - track->title = g_strdup( metaBundle.title().utf8() ); + if( metaBundle.isValidMedia() || !metaBundle.title().isEmpty() ) + track->title = g_strdup( metaBundle.title().utf8() ); + else + track->title = g_strdup( metaBundle.url().filename().utf8() ); track->album = g_strdup( metaBundle.album()->utf8() ); track->artist = g_strdup( metaBundle.artist()->utf8() ); track->genre = g_strdup( metaBundle.genre()->utf8() ); + + track->unk208 = 0x01; // for audio if(type=="wav") { |