Support and General Use > Audio Playback, Database and Playlists
Patch for APE tags on MP3s?
Llorean:
Yes, I think mp3gain still does unless you explicitly tell it not to.
Lear:
--- Quote from: saratoga on April 21, 2008, 07:35:04 PM ---It wasn't implemented very efficiently, and a lot of people here were opposed to supporting non-ID3 tag formats.
--- End quote ---
Hrmph, what was so inefficient about it, may I ask (other than needing extra file seeks and such)? :D
saratoga:
--- Quote from: Lear on April 22, 2008, 06:08:40 AM ---
--- Quote from: saratoga on April 21, 2008, 07:35:04 PM ---It wasn't implemented very efficiently, and a lot of people here were opposed to supporting non-ID3 tag formats.
--- End quote ---
Hrmph, what was so inefficient about it, may I ask (other than needing extra file seeks and such)? :D
--- End quote ---
The extra seek wasn't combined with the seek for the ID3v1 tag (which would be only a few hundred bytes away). That was the main problem as I recall.
zajacattack:
--- Quote from: saratoga on April 22, 2008, 02:54:22 PM ---The extra seek wasn't combined with the seek for the ID3v1 tag (which would be only a few hundred bytes away). That was the main problem as I recall.
--- End quote ---
Were it to be implemented this way, might it be accepted?
preglow:
The problem is how APE tags might interact with ID3 tags. We've already removed the ID3v1/ID3v2 priority option, so the first thing we look for is an ID3v2 tag, which is located at the start of a file. APE tags are located at the end of a file, so what to do if a file has both ID3v2 and APE? Also, what do we do if the APE tag is appended to the file before an ID3v1 tag? Look for both? We're not going to add an option for tag parsing again, so some way to handle this automatically in a way that makes sense needs to be found, and I'm not convinced there is one. People should just stick to ID3 :>
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version