Thread: Re: [Audacity-devel] Back to ID3v2 metadata in WAV files
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Federico M. <fm...@fc...> - 2013-08-01 10:49:04
|
Martyn, >>That looks like a good idea, to get Audacity 'label' tracks into / out >>of wav files, but I know very little about ID3 tags. Is all this >>supported / standardised? > >Yes, wav format is a standard Sorry, I reag again what I have written and I see that I didn't answer your question. You were intereted in ID3 rather than cues, labels and notes. ID3 is sort of an unofficial standard. It can be found in http://www.id3.org/ At this moment that website is down, but I could manage to access google cache: <http://webcache.googleusercontent.com/search?q=cache:i7uSuXJiAkAJ:id3.org/id3v2.3.0+&cd=2&hl=es&ct=clnk&gl=ar>http://webcache.googleusercontent.com/search?q=cache:i7uSuXJiAkAJ:id3.org/id3v2.3.0+&cd=2&hl=es&ct=clnk&gl=ar There you have the informal standard as they themselves call it. As to cues, labels, notes, they are standardized by Microsoft, you can find the wav format easily on the internet. Regards, Federico |
From: Joel B. <bo...@ho...> - 2013-08-02 13:44:41
|
Problem of the ID3 tags not managed by WMP in the WAV files produced by Audacity: solved! Patch in attachment. Hello, I have analysed the WAV files produced by foobar2000, while patching Audacity WAV file with a hex editor. Everything went alright when I moved the "LIST" chunk from the beginning of the file to the end, just before the ID3 chunk. Normally, a well behaved WAV parser shouldn't care about the order in which the chunks are arranged, but this seems not to be the case for the Microsoft Windows Media Player. Modifying the source code has been very easy, and the patch is very short, but this patch has to be tested and discussed anyway, because moving the LIST chunk after the DATA chunk might be a nuisance for some other players. I don't know. Joel ---------------------------------------- > From: bo...@ho... > To: aud...@li... > Date: Fri, 2 Aug 2013 12:14:29 +0200 > Subject: Re: [Audacity-devel] Several "Export" commands for batch chains patch > > Gale wrote: > >> Hi Joel, >> >> I just noticed on Windows 7 x64 SP1 running English UK format that >> although Windows Media Player doesn't see the tags in a WAV file >> exported from Audacity, it does see them if I edit and save the tags >> in Foobar2000 before opening the file in WMP. To check, look at the >> File's properties in WMP. >> >> Can you replicate this and might it be worth looking into? I don't >> want to necessarily assume it's repeatable because I have >> dBPowerAmp on this machine which does sometimes cause more >> metadata to be seen by Windows apps. >> >> >> >> >> Gale >> > > ==> > > Hello Gale, > > Yes you are right, WMP can extract the ID3 tags from a file created by foobar2000 but not from a file exported from Audacity. > > At least at the condition that foobar200 creates this WAV file directly from the original mp3 file. > When i create a WAV file with AUdacity and modify its tags with foobar2000, WMP cannot read the ID3 tags anyway. > > There is certainly a difference between the ID3v2 metadata formatted by Audacity and the metadata formatted by foobar2000. > > We rely on "LIBID3TAG" to create the ID3 tags, and there is little that can be done inside Audacity code itself. > To avoid encoding mixture, i have tried to force the format to UTF16 and next to ISO_8859_1 but this makes no difference: foobar200 reads both formats without problem and WMP reads none of them! > Nevertheless i will continue more investigation using an Hex editor. > > > Best regards, > > Joel > ------------------------------------------------------------------------------ > Get your SQL database under version control now! > Version control is standard for application code, but databases havent > caught up. So what steps can you take to put your SQL databases under > version control? Why should you start doing it? Read more to find out. > http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel |
From: Federico M. <fm...@fc...> - 2013-08-06 22:41:55
|
Joel, >Problem of the ID3 tags not managed by WMP in >the WAV files produced by Audacity: solved! >Patch in attachment. Hello, I have analysed the >WAV files produced by foobar2000, while patching >Audacity WAV file with a hex editor. Everything >went alright when I moved the "LIST" chunk from >the beginning of the file to the end, just >before the ID3 chunk. Normally, a well behaved >WAV parser shouldn't care about the order in >which the chunks are arranged, but this seems >not to be the case for the Microsoft Windows >Media Player. Modifying the source code has been >very easy, and the patch is very short, but this >patch has to be tested and discussed anyway, >because moving the LIST chunk after the DATA >chunk might be a nuisance for some other players. I don't know. Joel May be including two copies, one at the begining as ID3v2 requires for streaming purposes (see at id3 webpage comments on changes from version 1 to vesrion 2) and another one at the end, would solve that possible compatibility issue. I've seen this metadata repetition elsewhere... I don't remember now... red¡gards, Federico |
From: Joel B. <bo...@ho...> - 2013-08-07 08:35:59
Attachments:
ExportPCM.cpp - LIST chunk twice.patch
|
Federico wrote: > May be including two copies, one at the begining > as ID3v2 requires for streaming purposes (see at > id3 webpage comments on changes from version 1 to > vesrion 2) and another one at the end, would > solve that possible compatibility issue. I've > seen this metadata repetition elsewhere... I don't remember now... > ==> Hello Federico, this seems to be an excellent idea. I have implemented it and it works. After all, nothing in the "WAV" standard forbids to repeat the same chunk twice. Here is the patch in attachment. The only drawback that i see could be about some players. This is not a problem for Audacity, but some player may allocate the memory for the metadata twice, and free it only once at the end of the thread... Should not be a problem when the software is well written: the metadata object is created only once and filled with every tag found in the WAV file (from "LIST" or "ID3" chunks). The metadata object will be filled twice with the same info, but this doesn't matter. In the case of Audacity this metadata will be overwritten by the metadata found in the ID3 chunk anyway... Best regards, Joel ---------------------------------------- > |
From: Gale A. <ga...@au...> - 2013-08-12 17:16:08
|
| From Joel Bouchat <bo...@ho...> | Wed, 7 Aug 2013 10:35:51 +0200 | Subject: [Audacity-devel] Back to ID3v2 metadata in WAV files > Federico wrote: > > May be including two copies, one at the begining > > as ID3v2 requires for streaming purposes (see at > > id3 webpage comments on changes from version 1 to > > vesrion 2) and another one at the end, would > > solve that possible compatibility issue. I've > > seen this metadata repetition elsewhere... I don't remember now... > > > > ==> > > Hello Federico, > > this seems to be an excellent idea. I have implemented it and it works. > After all, nothing in the "WAV" standard forbids to repeat the same chunk twice. > Here is the patch in attachment. > > The only drawback that i see could be about some players. > This is not a problem for Audacity, but some player may allocate the memory > for the metadata twice, and free it only once at the end of the thread... > Should not be a problem when the software is well written: the metadata > object is created only once and filled with every tag found in the WAV > file (from "LIST" or "ID3" chunks). > The metadata object will be filled twice with the same info, but this doesn't > matter. > In the case of Audacity this metadata will be overwritten by the metadata > found in the ID3 chunk anyway... Hello Joel, I tried this and no applications I tried (Windows Media Player, Foobar 2000 and VLC on all three platforms) are adversely affected. However I don't know what applications if any need the LIST chunk before the DATA chunk, so can't test that. Also do I assume replacing the "LIST" before the DATA chunk with "PAD " is known to be sufficient for such applications? Does it work because the size of "PAD " and "LIST" (at the bottom) is the same? Gale |
From: Joel B. <bo...@ho...> - 2013-08-12 23:16:23
|
Gale wrote: > Hello Joel, > > I tried this and no applications I tried (Windows Media Player, Foobar > 2000 and VLC on all three platforms) are adversely affected. > > However I don't know what applications if any need the LIST chunk > before the DATA chunk, so can't test that. > > Also do I assume replacing the "LIST" before the DATA chunk with > "PAD " is known to be sufficient for such applications? Does it work > because the size of "PAD " and "LIST" (at the bottom) is the same? > > > > Gale ==> Hello Gale, I don't know neither! Foobar2000 replaces the "LIST" chunk located at the beginning of the file by a "JUNK" chunk, similar to a "PAD " chunk... For sure, this "JUNK" chunk will never be used. Only streaming applications could be interested to find the metadata at the beginning of the file, but "WAV" format is seldom used for streaming, its bit rate is too high. Best regards, Joel > > ------------------------------------------------------------------------------ > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel |
From: Gale A. <ga...@au...> - 2013-08-12 23:58:29
|
| From Joel Bouchat <bo...@ho...> | Tue, 13 Aug 2013 01:16:16 +0200 | Subject: [Audacity-devel] Back to ID3v2 metadata in WAV files > Gale wrote: > > > Hello Joel, > > > > I tried this and no applications I tried (Windows Media Player, Foobar > > 2000 and VLC on all three platforms) are adversely affected. > > > > However I don't know what applications if any need the LIST chunk > > before the DATA chunk, so can't test that. > > > > Also do I assume replacing the "LIST" before the DATA chunk with > > "PAD " is known to be sufficient for such applications? Does it work > > because the size of "PAD " and "LIST" (at the bottom) is the same? > > > > > > > > Gale > > ==> Hello Gale, > > I don't know neither! Foobar2000 replaces the "LIST" chunk located > at the beginning of the file by a "JUNK" chunk, similar to a "PAD " > chunk... For sure, this "JUNK" chunk will never be used. > Only streaming applications could be interested to find the metadata > at the beginning of the file, but "WAV" format is seldom used for > streaming, its bit rate is too high. OK, but we definitely don't need to actually repeat the metadata (in the LIST chunk at the bottom) in a LIST chunk at the top? That is, if the genre is "Acid" you would find two instances of "Acid" by searching in a Hex Editor? What I am getting at is that there is only seemingly one LIST chunk (at the bottom). After the fmt subchunk at the top, there is no LIST chunk that I can see - just the "PAD " chunk identifier followed by its size, but the chunk only contains zeros after that. The next chunk is the data subchunk. If you aren't seeing that, is something wrong? Gale |
From: Martyn S. <mar...@gm...> - 2013-08-13 00:20:20
|
On 13/08/2013 00:58, Gale Andrews wrote: > > | From Joel Bouchat <bo...@ho...> > | Tue, 13 Aug 2013 01:16:16 +0200 > | Subject: [Audacity-devel] Back to ID3v2 metadata in WAV files >> Gale wrote: >> >>> Hello Joel, >>> >>> I tried this and no applications I tried (Windows Media Player, Foobar >>> 2000 and VLC on all three platforms) are adversely affected. >>> >>> However I don't know what applications if any need the LIST chunk >>> before the DATA chunk, so can't test that. >>> >>> Also do I assume replacing the "LIST" before the DATA chunk with >>> "PAD " is known to be sufficient for such applications? Does it work >>> because the size of "PAD " and "LIST" (at the bottom) is the same? >>> >>> >>> >>> Gale >> >> ==> Hello Gale, >> >> I don't know neither! Foobar2000 replaces the "LIST" chunk located >> at the beginning of the file by a "JUNK" chunk, similar to a "PAD " >> chunk... For sure, this "JUNK" chunk will never be used. >> Only streaming applications could be interested to find the metadata >> at the beginning of the file, but "WAV" format is seldom used for >> streaming, its bit rate is too high. > > OK, but we definitely don't need to actually repeat the metadata > (in the LIST chunk at the bottom) in a LIST chunk at the top? I don't understand that. "...we definitely don't need to..." followed by a "?" ? Do we have a problem here or not? Come on, QA (Gale), is this better than we have now? Does it produce a problem more than we have? What is the patch to commit? Or should I wait another week for you to argue it out? I'd like to see this committed before the next release. TTFN Martyn That is, > if the genre is "Acid" you would find two instances of "Acid" by > searching in a Hex Editor? > > What I am getting at is that there is only seemingly one LIST chunk > (at the bottom). After the fmt subchunk at the top, there is no > LIST chunk that I can see - just the "PAD " chunk identifier followed > by its size, but the chunk only contains zeros after that. > > The next chunk is the data subchunk. > > If you aren't seeing that, is something wrong? > > > > Gale > > > > ------------------------------------------------------------------------------ > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |
From: Gale A. <ga...@au...> - 2013-08-13 01:19:32
|
| From Martyn Shaw <mar...@gm...> | Tue, 13 Aug 2013 01:20:13 +0100 | Subject: [Audacity-devel] Back to ID3v2 metadata in WAV files > > On 13/08/2013 00:58, Gale Andrews wrote: > > > > | From Joel Bouchat <bo...@ho...> > > | Tue, 13 Aug 2013 01:16:16 +0200 > > | Subject: [Audacity-devel] Back to ID3v2 metadata in WAV files > >> Gale wrote: > >> > >>> Hello Joel, > >>> > >>> I tried this and no applications I tried (Windows Media Player, Foobar > >>> 2000 and VLC on all three platforms) are adversely affected. > >>> > >>> However I don't know what applications if any need the LIST chunk > >>> before the DATA chunk, so can't test that. > >>> > >>> Also do I assume replacing the "LIST" before the DATA chunk with > >>> "PAD " is known to be sufficient for such applications? Does it work > >>> because the size of "PAD " and "LIST" (at the bottom) is the same? > >>> > >>> > >>> > >>> Gale > >> > >> ==> Hello Gale, > >> > >> I don't know neither! Foobar2000 replaces the "LIST" chunk located > >> at the beginning of the file by a "JUNK" chunk, similar to a "PAD " > >> chunk... For sure, this "JUNK" chunk will never be used. > >> Only streaming applications could be interested to find the metadata > >> at the beginning of the file, but "WAV" format is seldom used for > >> streaming, its bit rate is too high. > > > > OK, but we definitely don't need to actually repeat the metadata > > (in the LIST chunk at the bottom) in a LIST chunk at the top? > > I don't understand that. "...we definitely don't need to..." followed > by a "?" ? Do we have a problem here or not? > > Come on, QA (Gale), is this better than we have now? Does it produce > a problem more than we have? What is the patch to commit? Either patch as I tested them is a big improvement. Windows will now see LIST tags in WAV files (whichever ones that both Audacity and Windows support). The choice between the patches is that this patch tries to help apps that need the LIST tags before the audio data. I thought the patch was thus going to duplicate the LIST chunk before the data. But seemingly this patch still only writes one LIST chunk, relying on a "PAD " chunk before the data instead of a duplicate LIST chunk. As I said, I don't know if this a practical problem unless I find an app that needs the LIST chunk at the top (or set some WAV streaming up somehow). I guess it could be a practical problem. Gale > That is, > > if the genre is "Acid" you would find two instances of "Acid" by > > searching in a Hex Editor? > > > > What I am getting at is that there is only seemingly one LIST chunk > > (at the bottom). After the fmt subchunk at the top, there is no > > LIST chunk that I can see - just the "PAD " chunk identifier followed > > by its size, but the chunk only contains zeros after that. > > > > The next chunk is the data subchunk. > > > > If you aren't seeing that, is something wrong? > > > > > > > > Gale |
From: Joel B. <bo...@ho...> - 2013-08-13 11:54:33
Attachments:
ExportPCM_LIST_Album_and_Track_Tags_Implement.patch
|
Hello, i think that we are discussing about something which is not a real problem. Some explanation: 1) To be compatible with Window, the "LIST" patch within a wav file must absolutely be located at the end of the File, after the data chunk. 2) For streaming applications, it is nice to get the metadata before receiving the audio data itself. 3) When we duplicate the "LIST" metadata, "libsndfile" replaces the ID of the first occurrence of the "LIST" chunk with a "PAD " chunk (but the content is maintained). Some observation: 1) the same happens in foobar2000: the first "LIST" chunk ID is replaced with a "JUNK" chunk and the useful "LIST" metadata is always moved the end when not already there. 2) I doubt that any streaming application will ever use those "PAD " or "JUNK" metadata. 3) Moreover, PCM WAV format is almost never used for streaming because of its higher bit-rate. Conclusion: 1) Considering that the compatibility with Windows is more important that with hypothetic streaming, i propose that we keep only ONE "LIST" chunk AFTER the "DATA" chunk. 2) "libsndfile" doesn't process the "Album" and "track" tags correctly. Those tags are important. "libsndfile" must be (slightly) updated. It is done in the patch. ==> In attachment you will find the patch that i propose for commitment. It is exactly the same as the one already checked by Gale, but with only a single "AddStrings()" to create a single "LIST" chunk. Best regards, Joel ---------------------------------------- > Date: Tue, 13 Aug 2013 02:19:23 +0100 > From: ga...@au... > To: aud...@li... > Subject: Re: [Audacity-devel] Back to ID3v2 metadata in WAV files > > > | From Martyn Shaw <mar...@gm...> > | Tue, 13 Aug 2013 01:20:13 +0100 > | Subject: [Audacity-devel] Back to ID3v2 metadata in WAV files >> >> On 13/08/2013 00:58, Gale Andrews wrote: >>> >>> | From Joel Bouchat <bo...@ho...> >>> | Tue, 13 Aug 2013 01:16:16 +0200 >>> | Subject: [Audacity-devel] Back to ID3v2 metadata in WAV files >>>> Gale wrote: >>>> >>>>> Hello Joel, >>>>> >>>>> I tried this and no applications I tried (Windows Media Player, Foobar >>>>> 2000 and VLC on all three platforms) are adversely affected. >>>>> >>>>> However I don't know what applications if any need the LIST chunk >>>>> before the DATA chunk, so can't test that. >>>>> >>>>> Also do I assume replacing the "LIST" before the DATA chunk with >>>>> "PAD " is known to be sufficient for such applications? Does it work >>>>> because the size of "PAD " and "LIST" (at the bottom) is the same? >>>>> >>>>> >>>>> >>>>> Gale >>>> >>>> ==> Hello Gale, >>>> >>>> I don't know neither! Foobar2000 replaces the "LIST" chunk located >>>> at the beginning of the file by a "JUNK" chunk, similar to a "PAD " >>>> chunk... For sure, this "JUNK" chunk will never be used. >>>> Only streaming applications could be interested to find the metadata >>>> at the beginning of the file, but "WAV" format is seldom used for >>>> streaming, its bit rate is too high. >>> >>> OK, but we definitely don't need to actually repeat the metadata >>> (in the LIST chunk at the bottom) in a LIST chunk at the top? >> >> I don't understand that. "...we definitely don't need to..." followed >> by a "?" ? Do we have a problem here or not? >> >> Come on, QA (Gale), is this better than we have now? Does it produce >> a problem more than we have? What is the patch to commit? > > Either patch as I tested them is a big improvement. Windows > will now see LIST tags in WAV files (whichever ones that both > Audacity and Windows support). > > The choice between the patches is that this patch tries to help > apps that need the LIST tags before the audio data. I thought > the patch was thus going to duplicate the LIST chunk before the > data. But seemingly this patch still only writes one LIST chunk, > relying on a "PAD " chunk before the data instead of a duplicate > LIST chunk. > > As I said, I don't know if this a practical problem unless I find > an app that needs the LIST chunk at the top (or set some > WAV streaming up somehow). I guess it could be a practical > problem. > > > > Gale > > >> That is, >>> if the genre is "Acid" you would find two instances of "Acid" by >>> searching in a Hex Editor? >>> >>> What I am getting at is that there is only seemingly one LIST chunk >>> (at the bottom). After the fmt subchunk at the top, there is no >>> LIST chunk that I can see - just the "PAD " chunk identifier followed >>> by its size, but the chunk only contains zeros after that. >>> >>> The next chunk is the data subchunk. >>> >>> If you aren't seeing that, is something wrong? >>> >>> >>> >>> Gale > > > ------------------------------------------------------------------------------ > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel |
From: Gale A. <ga...@au...> - 2013-08-13 19:55:58
|
| From Joel Bouchat <bo...@ho...> | Tue, 13 Aug 2013 13:54:22 +0200 | Subject: [Audacity-devel] Back to ID3v2 metadata in WAV files > i think that we are discussing about something which is not a > real problem. > > Some explanation: > > 1) To be compatible with Window, the "LIST" patch within a > wav file must absolutely be located at the end of the File, after the > data chunk. > > 2) For streaming applications, it is nice to get the metadata > before receiving the audio data itself. > > 3) When we duplicate the "LIST" metadata, "libsndfile" > replaces the ID of the first occurrence of the "LIST" chunk with a "PAD " > chunk (but the content is maintained). Hi Joel, OK, I had to ask as I did not know the duplication would occur this way. > Some observation: > > 1) the same happens in foobar2000: the first "LIST" chunk ID > is replaced with a "JUNK" chunk and the useful "LIST" metadata is always > moved the end when not already there. > > 2) I doubt that any streaming application will ever use those "PAD " > or "JUNK" metadata. > > 3) Moreover, PCM WAV format is almost never used for streaming because > of its higher bit-rate. > > Conclusion: > > 1) Considering that the compatibility with Windows is more important > that with hypothetic streaming, i propose that we keep only ONE "LIST" > chunk AFTER the "DATA" chunk. I agree Windows compatibility seems more important. But could there also be legacy (non-streaming) apps that need the LIST metadata before the data? Also might there not be streaming apps that use the smaller "uncompressed" formats like U-Law or GSM? Are you reasonably confident that any apps that need to could reference the LIST metadata at the bottom from the "PAD " chunk? Or don't we know? > ==> In attachment you will find the patch that i propose for > commitment. It is exactly the same as the one already checked by Gale, > but with only a single "AddStrings()" to create a single "LIST" chunk. My reasoning is that we know the "PAD " chunk before the data does not harm Windows. So unless we know the "PAD " chunk can't be used to point to the single "LIST" chunk, making the chunk nothing but bloat, why not leave it in? For completeness, I had not actually tested your patch of 10 Aug 2013 10:56:49 +0200 which completes support for ITRK and IPRD. This works fine. Windows sees those two tags on my machine without dBPowerAmp, and Rhythmbox on Ubuntu sees them (it reads LIST tags for WAV). One minor problem - it seems Audacity isn't reading IGNR on import. I tested that by removing the ID3 chunk from an Audacity-exported WAV file, so that it could only read the LIST chunk. Gale > 2) "libsndfile" doesn't process the "Album" and "track" tags correctly. > Those tags are important. "libsndfile" must be (slightly) updated. It is > done in the patch. ------------------------------------ > > Date: Tue, 13 Aug 2013 02:19:23 +0100 > > From: ga...@au... > > To: aud...@li... > > Subject: Re: [Audacity-devel] Back to ID3v2 metadata in WAV files > > > > > > | From Martyn Shaw <mar...@gm...> > > | Tue, 13 Aug 2013 01:20:13 +0100 > > | Subject: [Audacity-devel] Back to ID3v2 metadata in WAV files > >> > >> On 13/08/2013 00:58, Gale Andrews wrote: > >>> > >>> | From Joel Bouchat <bo...@ho...> > >>> | Tue, 13 Aug 2013 01:16:16 +0200 > >>> | Subject: [Audacity-devel] Back to ID3v2 metadata in WAV files > >>>> Gale wrote: > >>>> > >>>>> Hello Joel, > >>>>> > >>>>> I tried this and no applications I tried (Windows Media Player, Foobar > >>>>> 2000 and VLC on all three platforms) are adversely affected. > >>>>> > >>>>> However I don't know what applications if any need the LIST chunk > >>>>> before the DATA chunk, so can't test that. > >>>>> > >>>>> Also do I assume replacing the "LIST" before the DATA chunk with > >>>>> "PAD " is known to be sufficient for such applications? Does it work > >>>>> because the size of "PAD " and "LIST" (at the bottom) is the same? > >>>>> > >>>>> > >>>>> > >>>>> Gale > >>>> > >>>> ==> Hello Gale, > >>>> > >>>> I don't know neither! Foobar2000 replaces the "LIST" chunk located > >>>> at the beginning of the file by a "JUNK" chunk, similar to a "PAD " > >>>> chunk... For sure, this "JUNK" chunk will never be used. > >>>> Only streaming applications could be interested to find the metadata > >>>> at the beginning of the file, but "WAV" format is seldom used for > >>>> streaming, its bit rate is too high. > >>> > >>> OK, but we definitely don't need to actually repeat the metadata > >>> (in the LIST chunk at the bottom) in a LIST chunk at the top? > >> > >> I don't understand that. "...we definitely don't need to..." followed > >> by a "?" ? Do we have a problem here or not? > >> > >> Come on, QA (Gale), is this better than we have now? Does it produce > >> a problem more than we have? What is the patch to commit? > > > > Either patch as I tested them is a big improvement. Windows > > will now see LIST tags in WAV files (whichever ones that both > > Audacity and Windows support). > > > > The choice between the patches is that this patch tries to help > > apps that need the LIST tags before the audio data. I thought > > the patch was thus going to duplicate the LIST chunk before the > > data. But seemingly this patch still only writes one LIST chunk, > > relying on a "PAD " chunk before the data instead of a duplicate > > LIST chunk. > > > > As I said, I don't know if this a practical problem unless I find > > an app that needs the LIST chunk at the top (or set some > > WAV streaming up somehow). I guess it could be a practical > > problem. > > > > > > > > Gale > > > > > >> That is, > >>> if the genre is "Acid" you would find two instances of "Acid" by > >>> searching in a Hex Editor? > >>> > >>> What I am getting at is that there is only seemingly one LIST chunk > >>> (at the bottom). After the fmt subchunk at the top, there is no > >>> LIST chunk that I can see - just the "PAD " chunk identifier followed > >>> by its size, but the chunk only contains zeros after that. > >>> > >>> The next chunk is the data subchunk. > >>> > >>> If you aren't seeing that, is something wrong? > >>> > >>> > >>> > >>> Gale |
From: Joel B. <bo...@ho...> - 2013-08-13 21:43:49
Attachments:
ExportPCM_LIST_Album_Track_Genre_Implement.patch
|
Gale wrote: ---------------------------------------- > > My reasoning is that we know the "PAD " chunk before the data > does not harm Windows. So unless we know the "PAD " chunk > can't be used to point to the single "LIST" chunk, making the chunk > nothing but bloat, why not leave it in? ==> This "PAD " chunk does no harm at all, but, as such, it is also completely useless... This chunk occupies the room of the erased "LIST" chunk but it contains no information, only "00 00 00 ...". When ""libsndfile" creates the second "LIST" chunk it automatically erases the first "LIST" chunk and replaces it with padding... I do not understand well your request. Do you want that i re-copy the genuine "LIST" chunk in place of this "PAD " chunk? (In some way, rebuild the chunk destroyed by "libsndfile"?). This is possible by writing directly to the file, but if i let the label "PAD ", this is useless because no application will ever examine padding, except for its length. If i replace the "PAD " label with "LIST" we will have two "LIST" chunks and i suppose that if "libsndfile" has removed one, there must be a good reason... A compromise would be to rename it "JUNK", but there is no big difference between "PAD" and "JUNK". Here are some old definitions that i have found on the Web: " JUNK (Filler) Chunk Added: 05/01/92 Author: IBM, Microsoft A JUNK chunk represents , filler or outdated information. It contains no relevant data; it is a space filler of arbitrary size. The JUNK chunk is defined as follows: <JUNK chunk> ? JUNK( <filler> ) where <filler> contains random data. PAD (Filler) Chunk Added: 07/15/92 Author: Microsoft A PAD chunk represents padding. It contains no relevant data; it is a space filler of arbitrary size. When duplicating the file, the copier should maintain the padding of the PAD chunk. Specifically, if the PAD chunk makes the next chunk align on a 2K boundary in the physical file, then this alignment should be preserved even if the size of the PAD chunk must change. The PAD chunk is defined as follows: <PAD chunk> ? PAD( <filler> ) where <filler> contains random data. > > For completeness, I had not actually tested your patch of 10 Aug 2013 > 10:56:49 +0200 which completes support for ITRK and IPRD. This works > fine. Windows sees those two tags on my machine without dBPowerAmp, > and Rhythmbox on Ubuntu sees them (it reads LIST tags for WAV). > > One minor problem - it seems Audacity isn't reading IGNR on import. I > tested that by removing the ID3 chunk from an Audacity-exported > WAV file, so that it could only read the LIST chunk. > ==> You are right Gale! I missed this one because the genre was given by the ID3 tag. Here is the updated patch to cope with Album, Track and Genre in the "LIST", on export and on import. Best regards Joel > > Gale > > >> 2) "libsndfile" doesn't process the "Album" and "track" tags correctly. >> Those tags are important. "libsndfile" must be (slightly) updated. It is >> done in the patch. > > > ------------------------------------ >>> Date: Tue, 13 Aug 2013 02:19:23 +0100 >>> From: ga...@au... >>> To: aud...@li... >>> Subject: Re: [Audacity-devel] Back to ID3v2 metadata in WAV files >>> >>> >>> | From Martyn Shaw <mar...@gm...> >>> | Tue, 13 Aug 2013 01:20:13 +0100 >>> | Subject: [Audacity-devel] Back to ID3v2 metadata in WAV files >>>> >>>> On 13/08/2013 00:58, Gale Andrews wrote: >>>>> >>>>> | From Joel Bouchat <bo...@ho...> >>>>> | Tue, 13 Aug 2013 01:16:16 +0200 >>>>> | Subject: [Audacity-devel] Back to ID3v2 metadata in WAV files >>>>>> Gale wrote: >>>>>> >>>>>>> Hello Joel, >>>>>>> >>>>>>> I tried this and no applications I tried (Windows Media Player, Foobar >>>>>>> 2000 and VLC on all three platforms) are adversely affected. >>>>>>> >>>>>>> However I don't know what applications if any need the LIST chunk >>>>>>> before the DATA chunk, so can't test that. >>>>>>> >>>>>>> Also do I assume replacing the "LIST" before the DATA chunk with >>>>>>> "PAD " is known to be sufficient for such applications? Does it work >>>>>>> because the size of "PAD " and "LIST" (at the bottom) is the same? >>>>>>> >>>>>>> >>>>>>> >>>>>>> Gale >>>>>> >>>>>> ==> Hello Gale, >>>>>> >>>>>> I don't know neither! Foobar2000 replaces the "LIST" chunk located >>>>>> at the beginning of the file by a "JUNK" chunk, similar to a "PAD " >>>>>> chunk... For sure, this "JUNK" chunk will never be used. >>>>>> Only streaming applications could be interested to find the metadata >>>>>> at the beginning of the file, but "WAV" format is seldom used for >>>>>> streaming, its bit rate is too high. >>>>> >>>>> OK, but we definitely don't need to actually repeat the metadata >>>>> (in the LIST chunk at the bottom) in a LIST chunk at the top? >>>> >>>> I don't understand that. "...we definitely don't need to..." followed >>>> by a "?" ? Do we have a problem here or not? >>>> >>>> Come on, QA (Gale), is this better than we have now? Does it produce >>>> a problem more than we have? What is the patch to commit? >>> >>> Either patch as I tested them is a big improvement. Windows >>> will now see LIST tags in WAV files (whichever ones that both >>> Audacity and Windows support). >>> >>> The choice between the patches is that this patch tries to help >>> apps that need the LIST tags before the audio data. I thought >>> the patch was thus going to duplicate the LIST chunk before the >>> data. But seemingly this patch still only writes one LIST chunk, >>> relying on a "PAD " chunk before the data instead of a duplicate >>> LIST chunk. >>> >>> As I said, I don't know if this a practical problem unless I find >>> an app that needs the LIST chunk at the top (or set some >>> WAV streaming up somehow). I guess it could be a practical >>> problem. >>> >>> >>> >>> Gale >>> >>> >>>> That is, >>>>> if the genre is "Acid" you would find two instances of "Acid" by >>>>> searching in a Hex Editor? >>>>> >>>>> What I am getting at is that there is only seemingly one LIST chunk >>>>> (at the bottom). After the fmt subchunk at the top, there is no >>>>> LIST chunk that I can see - just the "PAD " chunk identifier followed >>>>> by its size, but the chunk only contains zeros after that. >>>>> >>>>> The next chunk is the data subchunk. >>>>> >>>>> If you aren't seeing that, is something wrong? >>>>> >>>>> >>>>> >>>>> Gale > > ------------------------------------------------------------------------------ > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel |
From: Gale A. <ga...@au...> - 2013-08-14 00:41:05
|
| From Joel Bouchat <bo...@ho...> | Tue, 13 Aug 2013 23:43:39 +0200 | Subject: [Audacity-devel] Back to ID3v2 metadata in WAV files > Gale wrote: > ---------------------------------------- > > > > My reasoning is that we know the "PAD " chunk before the data > > does not harm Windows. So unless we know the "PAD " chunk > > can't be used to point to the single "LIST" chunk, making the chunk > > nothing but bloat, why not leave it in? > > ==> This "PAD " chunk does no harm at all, but, as such, it is also completely useless... > This chunk occupies the room of the erased "LIST" chunk but it contains > no information, only "00 00 00 ...". > > When ""libsndfile" creates the second "LIST" chunk it automatically > erases the first "LIST" chunk and replaces it with padding... > > I do not understand well your request. Do you want that i re-copy > the genuine "LIST" chunk in place of this "PAD " chunk? (In some way, > rebuild the chunk destroyed by "libsndfile"?). > > This is possible by writing directly to the file, but if i let the label "PAD ", > this is useless because no application will ever examine padding, except > for its length. > > If i replace the "PAD " label with "LIST" we will have two "LIST" chunks > and i suppose that if "libsndfile" has removed one, there must be a good > reason... > > A compromise would be to rename it "JUNK", but there is no big > difference between "PAD" and "JUNK". Here are some old definitions that > i have found on the Web: > > > " > JUNK (Filler) Chunk > > Added: 05/01/92 > Author: IBM, Microsoft > > A JUNK chunk represents , filler or outdated information. It contains no > relevant data; it is a space filler of arbitrary size. The JUNK chunk is > defined as follows: > > <JUNK chunk> ? JUNK( <filler> ) > > where <filler> contains random data. > > > PAD (Filler) Chunk > > Added: 07/15/92 > Author: Microsoft > > A PAD chunk represents padding. It contains no relevant data; it is a space > filler of arbitrary size. When duplicating the file, the copier should > maintain the padding of the PAD chunk. Specifically, if the PAD chunk makes > the next chunk align on a 2K boundary in the physical file, then this > alignment should be preserved even if the size of the PAD chunk must change. > The PAD chunk is defined as follows: > > <PAD chunk> ? PAD( <filler> ) > > where <filler> contains random data. Hi Joel, OK I thought you yourself had chosen a "PAD " chunk as the "possible solution" to providing metadata at the top of the file. You're saying clearly now it's bloat, and that patch is unacceptable for AIFF: * It writes two SSND chunks * Riffpad cannot understand the exported file even if all the optional chunks have an even number of bytes * iTtunes can't see the metadata in the file so let's forget that. The current working, tested patch (it imports IGNR fine) is: http://audacity.238276.n2.nabble.com/attachment/7558859/0/ExportPCM_LIST_Album_Track_Genre_Implement.patch . This assumes we agree to patch lib-src/libsndfile/src/wav.c. I agree with Joel that it's a serious omission not to write IPRD (Album Title) and ITRK (Track Number) in WAV LIST chunks. I can't find any definite indication two LIST chunks is illegal but I've qualms about it now I understand libsndfile is removing the first chunk. From my tests, Windows doesn't see any LIST tags in WAV if I duplicate them in top and bottom of the file. So if we commit the patch linked above perhaps we should just see if there are complaints about the change and consider where to go from there e.g. some kind of option on where to place the LIST chunk. Thanks, Gale > > For completeness, I had not actually tested your patch of 10 Aug 2013 > > 10:56:49 +0200 which completes support for ITRK and IPRD. This works > > fine. Windows sees those two tags on my machine without dBPowerAmp, > > and Rhythmbox on Ubuntu sees them (it reads LIST tags for WAV). > > > > One minor problem - it seems Audacity isn't reading IGNR on import. I > > tested that by removing the ID3 chunk from an Audacity-exported > > WAV file, so that it could only read the LIST chunk. > > > ==> You are right Gale! > I missed this one because the genre was given by the ID3 tag. > Here is the updated patch to cope with Album, Track and Genre in the "LIST", on export and on import. > > > Best regards > > Joel > > > > > > Gale > > > > > >> 2) "libsndfile" doesn't process the "Album" and "track" tags correctly. > >> Those tags are important. "libsndfile" must be (slightly) updated. It is > >> done in the patch. > > > > > > ------------------------------------ > >>> Date: Tue, 13 Aug 2013 02:19:23 +0100 > >>> From: ga...@au... > >>> To: aud...@li... > >>> Subject: Re: [Audacity-devel] Back to ID3v2 metadata in WAV files > >>> > >>> > >>> | From Martyn Shaw <mar...@gm...> > >>> | Tue, 13 Aug 2013 01:20:13 +0100 > >>> | Subject: [Audacity-devel] Back to ID3v2 metadata in WAV files > >>>> > >>>> On 13/08/2013 00:58, Gale Andrews wrote: > >>>>> > >>>>> | From Joel Bouchat <bo...@ho...> > >>>>> | Tue, 13 Aug 2013 01:16:16 +0200 > >>>>> | Subject: [Audacity-devel] Back to ID3v2 metadata in WAV files > >>>>>> Gale wrote: > >>>>>> > >>>>>>> Hello Joel, > >>>>>>> > >>>>>>> I tried this and no applications I tried (Windows Media Player, Foobar > >>>>>>> 2000 and VLC on all three platforms) are adversely affected. > >>>>>>> > >>>>>>> However I don't know what applications if any need the LIST chunk > >>>>>>> before the DATA chunk, so can't test that. > >>>>>>> > >>>>>>> Also do I assume replacing the "LIST" before the DATA chunk with > >>>>>>> "PAD " is known to be sufficient for such applications? Does it work > >>>>>>> because the size of "PAD " and "LIST" (at the bottom) is the same? > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Gale > >>>>>> > >>>>>> ==> Hello Gale, > >>>>>> > >>>>>> I don't know neither! Foobar2000 replaces the "LIST" chunk located > >>>>>> at the beginning of the file by a "JUNK" chunk, similar to a "PAD " > >>>>>> chunk... For sure, this "JUNK" chunk will never be used. > >>>>>> Only streaming applications could be interested to find the metadata > >>>>>> at the beginning of the file, but "WAV" format is seldom used for > >>>>>> streaming, its bit rate is too high. > >>>>> > >>>>> OK, but we definitely don't need to actually repeat the metadata > >>>>> (in the LIST chunk at the bottom) in a LIST chunk at the top? > >>>> > >>>> I don't understand that. "...we definitely don't need to..." followed > >>>> by a "?" ? Do we have a problem here or not? > >>>> > >>>> Come on, QA (Gale), is this better than we have now? Does it produce > >>>> a problem more than we have? What is the patch to commit? > >>> > >>> Either patch as I tested them is a big improvement. Windows > >>> will now see LIST tags in WAV files (whichever ones that both > >>> Audacity and Windows support). > >>> > >>> The choice between the patches is that this patch tries to help > >>> apps that need the LIST tags before the audio data. I thought > >>> the patch was thus going to duplicate the LIST chunk before the > >>> data. But seemingly this patch still only writes one LIST chunk, > >>> relying on a "PAD " chunk before the data instead of a duplicate > >>> LIST chunk. > >>> > >>> As I said, I don't know if this a practical problem unless I find > >>> an app that needs the LIST chunk at the top (or set some > >>> WAV streaming up somehow). I guess it could be a practical > >>> problem. > >>> > >>> > >>> > >>> Gale |