Thread: Re: [Audacity-devel] Metadata in RIFF files (was: Back to ID3v2 metadata in WAV files) (Page 2)
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Steve t. F. <ste...@gm...> - 2013-08-16 13:20:09
|
I've raised it on the forum here: http://forum.audacityteam.org/viewtopic.php?f=20&t=74049 Steve On 16 August 2013 13:44, Peter Sampson <pet...@ya...> wrote: > Steve wrote: >>As a user of Audacity, my preference would be to be able to set it >>once, disable the Metadata Editor pop-up, and then forget about it, >>because I never use metadata in Audacity. > > A big +1 to that > > Like Steve I never use metadata in Audacity - I do that in iTunes > once I have exported the file from Audacity. > > Peter > > Peter Sampson > Tel: +44 (0)1625 524 780 > Mob: +44 (0)7732 278 299 > > From: Steve the Fiddle <ste...@gm...> > To: Audacity-Devel list <aud...@li...> > Sent: Friday, August 16, 2013 1:09 PM > > Subject: Re: [Audacity-devel] Metadata in RIFF files (was: Back to ID3v2 > metadata in WAV files) > > On 16 August 2013 12:56, Joel Bouchat <bo...@ho...> wrote: >> Hello Gale, Hello Steve, >> >> I can implement this check box for disabling the metadata anywhere: just >> tell me! >> >> As a USER of Audacity, my own preference is to implement it in the >> Metadata Edition dialog, because i did not disable the dialog pop up and i >> always have a look to the metadata before exporting. I seldom click on the >> "Option" button to get access to the format settings. For me, the default >> settings are ok: i always use FLAC or PCM format, at 16 bits (I cannot hear >> any difference between audio tracks at 16 bits or 24 bits!). > > As a user of Audacity, my preference would be to be able to set it > once, disable the Metadata Editor pop-up, and then forget about it, > because I never use metadata in Audacity. I don't personally mind > where that option is, though if it is in the Metadata Editor then > users will stumble across it the first time that they export. > >> >> Now, other users have probably other habitudes. Could the question be >> posted on the User forum? > > Yes, good idea. We can do that. > > Steve > >> >> For batch chains, i agree with Gale that a command which only applies to >> the next export is a little difficult to explain and it is not intuitive >> (non markovian process!) ... although there is rarely more than a single >> export command at the end of a chain... >> But i can add this option to every ExportXXX dialog box if you prefer... >> just tell me! >> >> Best regards, >> >> Joel >> >> ---------------------------------------- >>> Date: Fri, 16 Aug 2013 02:26:33 +0100 >>> From: ste...@gm... >>> To: aud...@li... >>> Subject: Re: [Audacity-devel] Metadata in RIFF files (was: Back to ID3v2 >>> metadata in WAV files) >>> >>> On 15 August 2013 22:16, Gale Andrews <ga...@au...> wrote: >>>> >>>> | From Joel Bouchat <bo...@ho...> >>>> | Thu, 15 Aug 2013 05:00:31 +0200 >>>> | Subject: [Audacity-devel] Metadata in RIFF files (was: Back to ID3v2 >>>> metadata in WAV files) >>>>> in the last patch that i posted about AIFF tag fixing, the ID3 tag is >>>>> at the end, but the other AIFF tags (NAME, AUTH, ANNO) are at the >>>>> beginning of the file before the SSND data. >>>>> This is the best solution for streaming. >>>>> But, since this might be a problem for the iPod,i have also created a >>>>> patch >>>>> where all the tags are at the end (as for a WAV file). >>>>> >>>>> Here are the two patches together, for experimenting. >>>> >>>> OK thanks. I'll try both. >>>> >>>> >>>>> Since the "Edit Metadata Tags" dialog pops up when exporting, the >>>>> best place to install this option is to add a check box within this >>>>> dialog box. I could easily do that. >>>> >>>> Thanks, though the problem remains that the choice to make "Edit >>>> Metadata Tags" appear at export is a currently a Preference. >>>> >>>> So if anyone turns the metadata dialog off in Prefs, any "no metadata" >>>> checkbox it contains will not be so easily found. If that checkbox is >>>> off (as it would be by default) then if metadata is stored by the >>>> editor it will still be exported even if the dialogue does not appear. >>>> >>>> So I still think we should move the Pref to show Metadata Editor to >>>> the export dialogues to make it easier to access, and make that >>>> control also decide if metadata is exported or not. >>>> >>>> But if you've any input how you would fix bug 551 please let us >>>> know your ideas (probably a separate topic). >>>> >>>> >>>>> The problem is different for the "chain" exportation commands >>>>> running in batch mode. Adding a check box and an extra parameter to >>>>> every "export" command would be tedious. A simpler solution is to add >>>>> a new command "No_Metadata" (?) that the user can install in the chain >>>>> before an "ExportXXX" command. I could also do that. >>>> >>>> Thanks for thinking about that. >>>> >>>> What if a user wanted metadata for one format and not for another >>>> (e.g. metadata for an MP3/MP4 file but none for a WAV copy that >>>> was meant for CD burning or for an app that didn't read WAV metadata)? >>>> >>>> It would be tedious to make two Chains for that case. >>> >>> "Tedious" is a lot better than "impossible", >>> Steve >>> >>>> >>>> You could do it by making a "No Metadata" command in a Chain only >>>> apply to formats above that command, but would it be intuitive? >>>> >>>> >>>> >>>> Gale >>>> >>>> >>>>> ---------------------------------------- >>>>>> Date: Thu, 15 Aug 2013 01:06:12 +0100 >>>>>> From: ga...@au... >>>>>> To: aud...@li... >>>>>> Subject: Re: [Audacity-devel] Metadata in RIFF files (was: Back to >>>>>> ID3v2 metadata in WAV files) >>>>>> >>>>>> >>>>>> | From Steve the Fiddle <ste...@gm...> >>>>>> | Tue, 13 Aug 2013 23:53:21 +0100 >>>>>> | Subject: [Audacity-devel] Metadata in RIFF files (was: Back to ID3v2 >>>>>> metadata in WAV files) >>>>>>>> On 13 August 2013 22:05, Gale Andrews <ga...@au...> wrote: >>>>>> [...] >>>>>>>> >>>>>>>> iTunes deletes the optional chunks if you create >>>>>>>> an AIFF version of the file, so that is the apparent workaround for >>>>>>>> the problem. >>>>>>>> >>>>>>>> My guess is it would be too complicated to offer users a choice >>>>>>>> of not exporting certain chunks (where the format exports more >>>>>>>> than one chunk for a piece of metadata). >>>>>>>> >>>>>>> >>>>>>> An option to disable all metadata need not be confusing, and would >>>>>>> solve >>>>>>> the problem of tracks not playing on the iPod Classic. All that would >>>>>>> be >>>>>>> required in the interface is a checkbox in the metadata editor. If it >>>>>>> also >>>>>>> greyed out the text fields in the editor then it would be blindingly >>>>>>> obvious. This would also be useful in other cases where metadata is >>>>>>> not >>>>>>> wanted (it is all too easy for unwanted metadata to slip into >>>>>>> multi-track >>>>>>> projects if audio is imported). >>>>>> >>>>>> Agreed that an option to disable all metadata is not confusing. >>>>>> It's an option we should have in any case IMO. >>>>>> >>>>>> "No metadata" is only a partial solution to the current Classic iPod >>>>>> issue. Users won't be aware until they search online that metadata >>>>>> is the reason for the iPod problem, so it only fixes the issue after >>>>>> it happens. It's still a nuisance for those who want to add the >>>>>> metadata in Audacity rather than elsewhere. >>>>>> >>>>>> Sorting out how to handle "no metadata" might be better done in >>>>>> the context of fixing bug 551: >>>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=551. >>>>>> >>>>>> That might mean a "no metadata" checkbox would be better in >>>>>> the export dialogues as a control to show Metadata Editor >>>>>> (instead of having a Preference to do that). >>>>>> >>>>>> I'll try Joel's patch(es) when I can (thanks to him). As far as I >>>>>> know there is no problem with ID3 at the end of AIFF files. >>>>>> iTunes leaves ID3 at the end after rewriting the file, so >>>>>> probably it's best not to move ID3 to the top. >>>>>> >>>>>> >>>>>> >>>>>> Gale >>>>>> >>>>>>>> Yes I guess to limit a regression risk we could kill the optional >>>>>>>> chunks >>>>>>>> only when encoding on Mac OS X. >>>>>>>> >>>>>>>> I noticed in Joel's patch that moves the LIST chunk to the end >>>>>>>> and adds "PAD ", the optional chunks now appear at the bottom >>>>>>>> of the file as well as at the top. >>>>>>>> >>>>>>>> Also that patch writes two SSND chunks if there is a LIST chunk. >>>>>>>> I think that might be a problem, so I'll retest with the patch >>>>>>>> version >>>>>>>> that does not duplicate the LIST chunk. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 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 >>> >>> >>> ------------------------------------------------------------------------------ >>> 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 >> >> ------------------------------------------------------------------------------ >> 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 > > ------------------------------------------------------------------------------ > 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 > > > > ------------------------------------------------------------------------------ > 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-17 02:01:49
|
| From Joel Bouchat <bo...@ho...> | Thu, 15 Aug 2013 05:00:31 +0200 | Subject: [Audacity-devel] Metadata in RIFF files (was: Back to ID3v2 metadata in WAV files) > in the last patch that i posted about AIFF tag fixing, the ID3 tag is > at the end, but the other AIFF tags (NAME, AUTH, ANNO) are at the > beginning of the file before the SSND data. > This is the best solution for streaming. > But, since this might be a problem for the iPod,i have also created > a patch where all the tags are at the end (as for a WAV file). > > Here are the two patches together, for experimenting. Thanks Joel. I built the patches on Windows and Mac and exported multiple files with odd numbers of characters in the labels (and also with even numbers of characters). I tested the files on all OS'es. Riffpad was OK with the files including the ones with odd-numbers of characters. It sees the space added to make the bytes an even number and counts the length correctly as indicated in ckSize. I'll post the files on the Forum and if we can get testing we'll see what Classic iPods and other Mac apps do with them. Two points * I added the optional "Copyright" AIFF text chunk "(c) " to my metadata. Riffpad could read the contents but named the chunk "?c? ". It may not matter very much and I don't have any other apps that can read these AIFF chunks. * dBPoweramp could not read the ID3 tags in the files where the AIFF chunks were at the end of the file. Other programs were not affected. Unless it proves important for iPod it's probably best to leave the AIFF chunks at the top. Thanks Gale |
From: Joel B. <bo...@ho...> - 2013-08-17 21:01:21
|
Gale wrote, > Two points > > * I added the optional "Copyright" AIFF text chunk "(c) " to my > metadata. Riffpad could read the contents but named the > chunk "?c? ". It may not matter very much and I don't have any > other apps that can read these AIFF chunks. ==> strange that the parenthesis are not recognized, their code is 7 bit standard ascii! I will have a look, but, as you say, this is not really important. > > * dBPoweramp could not read the ID3 tags in the files where the > AIFF chunks were at the end of the file. Other programs were > not affected. Unless it proves important for iPod it's probably > best to leave the AIFF chunks at the top. ==> What do you mean by "at the top" ? Seems to me that letting the AIFF chunks at the beginning of the file is better for streaming if no application is affected. Best regards, Joel |
From: Joel B. <bo...@ho...> - 2013-08-20 08:59:47
Attachments:
PCM_Import_Export_adapted.patch
|
Hello, >From release 12462, the patch to libsndfile "0001-Add-support-for-Album-and-Track-tags-in-RIFF-files-for-libsndfile" is committed. Thank you Richard! Here is the update to ImportPCM.cpp and ExportPCM.cpp to take advantage of this modification of "libsndfile". This patch also includes the small improvement to AIFF files: adding a space to odd length strings in the metadata tags. This improvement has been successfuly checked by Gale with dBPoweramp and Riffpad (and also with an Hex editor). It would be nice to also test it on a MAC and an iPod. For the commitment, the patches on WAV files and AIFF files cannot be dissociated. Both belongs to the "PCM" family processed by "libsndfile". Best regards, Joel |
From: Gale A. <ga...@au...> - 2013-08-21 01:33:36
|
| From Joel Bouchat <bo...@ho...> | Tue, 20 Aug 2013 10:59:40 +0200 | Subject: [Audacity-devel] Metadata in RIFF files (PCM import and export adapted) ) >From release 12462, the patch to libsndfile > "0001-Add-support-for-Album-and-Track-tags-in-RIFF-files-for-libsndfile" > is committed. Thank you Richard! > > Here is the update to ImportPCM.cpp and ExportPCM.cpp to take advantage of this > modification of "libsndfile". > > This patch also includes the small improvement to AIFF files: adding a space to odd > length strings in the metadata tags. This improvement has been > successfuly checked by Gale with dBPoweramp and Riffpad (and also with > an Hex editor). > It would be nice to also test it on a MAC and an iPod. I had tested that on Mac already. Koz and another person have tried AIFF files with the added metadata space on Classic iPods and they play fine. So far, the files also play on older Mac audio applications, so that is a good sign. This patch places the AIFF tag chunks at the beginning of the file as now (that's what I meant by "at the top"). I think this is the best place to put them. However just to confirm that Classic iPods and Mac apps played the files with the added metadata space both where the AIFF chunks were at the beginning of the file, or where they were moved to the end. Gale > For the commitment, the patches on WAV files and AIFF files cannot be dissociated. > Both belongs to the "PCM" family processed by "libsndfile". |
From: Steve t. F. <ste...@gm...> - 2013-08-20 15:05:57
|
On 20 August 2013 09:59, Joel Bouchat <bo...@ho...> wrote: > Hello, > > >From release 12462, the patch to libsndfile > "0001-Add-support-for-Album-and-Track-tags-in-RIFF-files-for-libsndfile" is > committed. Thank you Richard! > > Here is the update to ImportPCM.cpp and ExportPCM.cpp to take advantage of > this modification of "libsndfile". > > This patch also includes the small improvement to AIFF files: adding a > space to odd length strings in the metadata tags. This improvement has been > successfuly checked by Gale with dBPoweramp and Riffpad (and also with an > Hex editor). > It would be nice to also test it on a MAC and an iPod. > For the commitment, the patches on WAV files and AIFF files cannot be > dissociated. Both belongs to the "PCM" family processed by "libsndfile". > > I'm getting the following build error on Linux: export/ExportMultiple.cpp: In member function 'int ExportMultiple::ExportMultipleByLabel(bool, wxString, bool)': export/ExportMultiple.cpp:669:45: error: cannot pass objects of non-trivially-copyable type 'class wxString' through '...' export/ExportMultiple.cpp:672:45: error: cannot pass objects of non-trivially-copyable type 'class wxString' through '...' export/ExportMultiple.cpp:746:48: error: cannot pass objects of non-trivially-copyable type 'class wxString' through '...' export/ExportMultiple.cpp:780:47: error: cannot pass objects of non-trivially-copyable type 'class wxString' through '...' make[1]: *** [export/ExportMultiple.o] Error 1 make[1]: Leaving directory `/home/steve/sourcecode/audacity-clean/src' make: *** [audacity] Error 2 Steve > Best regards, > > Joel > |
From: Steve t. F. <ste...@gm...> - 2013-08-20 15:41:54
|
On 20 August 2013 16:05, Steve the Fiddle <ste...@gm...> wrote: > > > > On 20 August 2013 09:59, Joel Bouchat <bo...@ho...> wrote: > >> Hello, >> >> >From release 12462, the patch to libsndfile >> "0001-Add-support-for-Album-and-Track-tags-in-RIFF-files-for-libsndfile" is >> committed. Thank you Richard! >> >> Here is the update to ImportPCM.cpp and ExportPCM.cpp to take advantage >> of this modification of "libsndfile". >> >> This patch also includes the small improvement to AIFF files: adding a >> space to odd length strings in the metadata tags. This improvement has been >> successfuly checked by Gale with dBPoweramp and Riffpad (and also with an >> Hex editor). >> It would be nice to also test it on a MAC and an iPod. >> For the commitment, the patches on WAV files and AIFF files cannot be >> dissociated. Both belongs to the "PCM" family processed by "libsndfile". >> >> I'm getting the following build error on Linux: > > export/ExportMultiple.cpp: In member function 'int > ExportMultiple::ExportMultipleByLabel(bool, wxString, bool)': > export/ExportMultiple.cpp:669:45: error: cannot pass objects of > non-trivially-copyable type 'class wxString' through '...' > export/ExportMultiple.cpp:672:45: error: cannot pass objects of > non-trivially-copyable type 'class wxString' through '...' > export/ExportMultiple.cpp:746:48: error: cannot pass objects of > non-trivially-copyable type 'class wxString' through '...' > export/ExportMultiple.cpp:780:47: error: cannot pass objects of > non-trivially-copyable type 'class wxString' through '...' > make[1]: *** [export/ExportMultiple.o] Error 1 > make[1]: Leaving directory `/home/steve/sourcecode/audacity-clean/src' > make: *** [audacity] Error 2 > My mistake - that was just some cruft left over from a previous patch. It builds fine here when I do it right. Steve > > > Steve > > > >> Best regards, >> >> Joel >> > |
From: Richard A. <ri...@au...> - 2013-08-21 19:06:39
Attachments:
PCM_Import_Export_adapted-v2.patch
|
On Tue, 20 Aug 2013 10:59:40 +0200 Joel Bouchat <bo...@ho...> wrote: > Here is the update to ImportPCM.cpp and ExportPCM.cpp to take > advantage of this modification of "libsndfile". > > This patch also includes the small improvement to AIFF files: adding > a space to odd length strings in the metadata tags. This improvement > has been successfuly checked by Gale with dBPoweramp and Riffpad (and > also with an Hex editor). It would be nice to also test it on a MAC > and an iPod. For the commitment, the patches on WAV files and AIFF > files cannot be dissociated. Both belongs to the "PCM" family > processed by "libsndfile". I have only one question: when you say "Install the WAV metata in a "LIST" chunk at the end of the file" why do you then do (sf_format & SF_FORMAT_TYPEMASK) != SF_FORMAT_AIFF which in fact installs metadata for all libsndfile formats except AIFF (for instance WAVEX format export has it's tags at the end, although this would be logical to match WAV). Should this logic be inverted, so all formats other than WAV (and WAVEX?) get metadata (if supported) at the start of the file, and just WAV (and WAVEX?) gets them at the end because it works better? This would I think be consistent with the previous versions of Audacity, and there is no reason to change it (unlike WAV and AIFF) that I am aware of. I have re-worked the patch a little to use #defines for the string literals for tag names as this is more robust than repeating them everywhere (there were already some of these before you started), so the patch touches slightly more files than before. Richard |
From: Gale A. <ga...@au...> - 2013-08-21 22:32:46
|
| From Richard Ash <ri...@au...> | Wed, 21 Aug 2013 20:06:22 +0100 | Subject: [Audacity-devel] Metadata in RIFF files (PCM import and export adapted) ) > On Tue, 20 Aug 2013 10:59:40 +0200 > Joel Bouchat <bo...@ho...> wrote: > > Here is the update to ImportPCM.cpp and ExportPCM.cpp to take > > advantage of this modification of "libsndfile". > > > > This patch also includes the small improvement to AIFF files: adding > > a space to odd length strings in the metadata tags. This improvement > > has been successfuly checked by Gale with dBPoweramp and Riffpad (and > > also with an Hex editor). It would be nice to also test it on a MAC > > and an iPod. For the commitment, the patches on WAV files and AIFF > > files cannot be dissociated. Both belongs to the "PCM" family > > processed by "libsndfile". > > I have only one question: when you say > "Install the WAV metata in a "LIST" chunk at the end of the file" > why do you then do > (sf_format & SF_FORMAT_TYPEMASK) != SF_FORMAT_AIFF > which in fact installs metadata for all libsndfile formats except AIFF > (for instance WAVEX format export has it's tags at the end, although > this would be logical to match WAV). > > Should this logic be inverted, so all formats other than WAV (and > WAVEX?) get metadata (if supported) at the start of the file, and just > WAV (and WAVEX?) gets them at the end because it works better? This > would I think be consistent with the previous versions of Audacity, and > there is no reason to change it (unlike WAV and AIFF) that I am aware > of. I built Richard's version on Windows so far. Just noting the position with 2.0.3 and HEAD. For WAVEX, 2.0.3 and HEAD produce LIST tags at the start of the file (but no ID3 tags). Should WAVEX have ID3 tags? Foobar2000 adds ID3 to an Audacity-exported WAVEX file e.g. the TPOS tag. For WAV, 2.0.3 and HEAD have LIST tags at the start and HEAD also now has ID3 at the end. So the current patch moves LIST tags to the end for WAV and WAVEX. I must have missed the evidence that LIST tags work better at the end. But isn't there a small case that streaming or legacy apps want LIST tags at the start for WAV or WAVEX? I thought this argument was why we decided against moving the AIFF tags to the end? Gale > I have re-worked the patch a little to use #defines for the string > literals for tag names as this is more robust than repeating them > everywhere (there were already some of these before you started), so > the patch touches slightly more files than before. > > Richard |
From: Joel B. <bo...@ho...> - 2013-08-22 07:16:06
Attachments:
PCM_Import_Export_adapted 2.patch
|
Richard wrote: > I have only one question: when you say > "Install the WAV metata in a "LIST" chunk at the end of the file" > why do you then do > (sf_format & SF_FORMAT_TYPEMASK) != SF_FORMAT_AIFF > which in fact installs metadata for all libsndfile formats except AIFF > (for instance WAVEX format export has it's tags at the end, although > this would be logical to match WAV). > Should this logic be inverted, so all formats other than WAV (and > WAVEX?) get metadata (if supported) at the start of the file, and just > WAV (and WAVEX?) gets them at the end because it works better? This > would I think be consistent with the previous versions of Audacity, and > there is no reason to change it (unlike WAV and AIFF) that I am aware of. > I have re-worked the patch a little to use #defines for the string > literals for tag names as this is more robust than repeating them > everywhere (there were already some of these before you started), so > the patch touches slightly more files than before. Hello Richard, i have exported a file in every format available in "Other uncompressed files"->"Options", from "AIFF" to "XI" formats. Using an hex editor, i have checked the presence of the metadata chunks inside the files. Conclusion: only AIFF and WAV files have metadata inside. "libsndfile" do not install our metadata in other formats, probably that those formats do offer this facility, at least presently. In some formats, libsndfile adds tags about itself, but this is not our metadata. Therefore, we can say that presently testing SF_FORMAT_AIFF or SF_FORMAT_WAV is equivalent. BUT, this may change with some future version of libsndfile. In this case, you are right permuting the tests to give the preference to tagging at the beginning of the file is better, at least for streaming. ==> I have modified the source code this way. Your remark has also allowed me to find a failure in my patch: "WAVEX" is not a sub-format of "WAV", "SF_FORMAT_WAVEX" MUST be tested separately, especially for including and extracting the id3V2 tags. This works well in "WAVEX" files too. Here is the patch for ExportPCM.cpp and ImportPCM.cpp. Sorry you will have to joint your own modifications and this last patch manually... Best regards, Joel P.S. : i will be absent until tomorrow afternoon. ------------------------------------------------------------------------------ Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk _______________________________________________ audacity-devel mailing list aud...@li... https://lists.sourceforge.net/lists/listinfo/audacity-devel |
From: Richard A. <ri...@au...> - 2013-08-23 10:02:11
|
On Thu, 22 Aug 2013 09:15:59 +0200 Joel Bouchat <bo...@ho...> wrote: > > i have exported a file in every format available in "Other > uncompressed files"->"Options", from "AIFF" to "XI" formats. Using an > hex editor, i have checked the presence of the metadata chunks inside > the files. Conclusion: only AIFF and WAV files have metadata inside. > "libsndfile" do not install our metadata in other formats, probably > that those formats do offer this facility, at least presently. In > some formats, libsndfile adds tags about itself, but this is not our > metadata. > > Therefore, we can say that presently testing SF_FORMAT_AIFF or > SF_FORMAT_WAV is equivalent. > > BUT, this may change with some future version of libsndfile. In this > case, you are right permuting the tests to give the preference to > tagging at the beginning of the file is better, at least for > streaming. ==> I have modified the source code this way. > > Your remark has also allowed me to find a failure in my patch: > "WAVEX" is not a sub-format of "WAV", "SF_FORMAT_WAVEX" MUST be > tested separately, especially for including and extracting the id3V2 > tags. This works well in "WAVEX" files too. > > Here is the patch for ExportPCM.cpp and ImportPCM.cpp. > > Sorry you will have to joint your own modifications and this last > patch manually... I have merged the changes together (as far as I know, the only change you have made is to the two conditionals which I have updated into my working copy. It all builds fine for me so I have committed this patch into SVN. Thank you all for your help in developing and testing this. Richard |
From: Martyn S. <mar...@gm...> - 2013-08-24 23:02:43
|
Thanks to Joel for all his efforts, and to Richard for the review and commit! Martyn On 23/08/2013 11:01, Richard Ash wrote: > On Thu, 22 Aug 2013 09:15:59 +0200 > Joel Bouchat <bo...@ho...> wrote: >> >> i have exported a file in every format available in "Other >> uncompressed files"->"Options", from "AIFF" to "XI" formats. Using an >> hex editor, i have checked the presence of the metadata chunks inside >> the files. Conclusion: only AIFF and WAV files have metadata inside. >> "libsndfile" do not install our metadata in other formats, probably >> that those formats do offer this facility, at least presently. In >> some formats, libsndfile adds tags about itself, but this is not our >> metadata. >> >> Therefore, we can say that presently testing SF_FORMAT_AIFF or >> SF_FORMAT_WAV is equivalent. >> >> BUT, this may change with some future version of libsndfile. In this >> case, you are right permuting the tests to give the preference to >> tagging at the beginning of the file is better, at least for >> streaming. ==> I have modified the source code this way. >> >> Your remark has also allowed me to find a failure in my patch: >> "WAVEX" is not a sub-format of "WAV", "SF_FORMAT_WAVEX" MUST be >> tested separately, especially for including and extracting the id3V2 >> tags. This works well in "WAVEX" files too. >> >> Here is the patch for ExportPCM.cpp and ImportPCM.cpp. >> >> Sorry you will have to joint your own modifications and this last >> patch manually... > > I have merged the changes together (as far as I know, the only change > you have made is to the two conditionals which I have updated into my > working copy. It all builds fine for me so I have committed this > patch into SVN. > > Thank you all for your help in developing and testing this. > > Richard > > ------------------------------------------------------------------------------ > Introducing Performance Central, a new site from SourceForge and > AppDynamics. Performance Central is your source for news, insights, > analysis and resources for efficient Application Performance Management. > Visit us today! > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |
From: Vaughan J. <va...@au...> - 2013-08-25 00:58:19
|
+1. :-) - V On 8/24/2013 4:02 PM, Martyn Shaw wrote: > Thanks to Joel for all his efforts, and to Richard for the review and > commit! > > Martyn |
From: Joel B. <bo...@ho...> - 2013-08-14 12:13:22
|
Hello Steve, hello Gale, here is a patch wich adjusts the AIFF metadata chunks to even lengths I have added a space to the even length strings in such a way that the total length (including '\0' ending char) is also even. This way the labels "NAME", "AUTH", "ANNO", are aligned on even addresses. But, maybe that i have not well understood, maybe that this is the string length (without '\0') that must be even...? Another question: in AIFF files, we are not obliged to install the Metadata at the end, we could as well let it at the beginning of the file, should i modify the code in this way? ==> You will find attached at second patch which implements the AIFF tags in this way. I have no way for testing all this, foobar2000 doesn't recognize aiff metadata and i have no iPod and no MAC. Best regards, Joel ________________________________ > Date: Tue, 13 Aug 2013 23:53:21 +0100 > From: ste...@gm... > To: aud...@li... > Subject: Re: [Audacity-devel] Metadata in RIFF files (was: Back to > ID3v2 metadata in WAV files) > > > > > On 13 August 2013 22:05, Gale Andrews > <ga...@au...<mailto:ga...@au...>> wrote: > > | From Joel Bouchat <bo...@ho...<mailto:bo...@ho...>> > | Tue, 13 Aug 2013 22:05:50 +0200 > | Subject: [Audacity-devel] Metadata in RIFF files (was: Back to ID3v2 > metadata in WAV files) > > Steve wrote: > > > > ---------------------------------------- > >> Date: Tue, 13 Aug 2013 16:31:52 +0100 > >> From: ste...@gm...<mailto:ste...@gm...> > >> To: > aud...@li...<mailto:aud...@li...> > >> Subject: [Audacity-devel] Metadata in RIFF files (was: Back to > ID3v2 metadata in WAV files) > >> > >> I've not been following this (Back to ID3v2 metadata in WAV files) > >> thread closely as I don't generally use metadata, but as the topic is > >> about changing the metadata in RIFF files I think it is relevant to > >> mention an issue that has recently been identified on the Audacity > >> forum concerning metadata in AIFF files. > >> > >> Currently Audacity includes "NAME", "AUTH", "ANNO" and "ID3 " chunks. > >> "NAME" contains Audacity "Track Title" > >> "AUTH" contains Audacity "Artist Name" > >> "ANNO" contains Audacity "Comments" > >> "ID3 " contains Audacity "Album Title, Track Title, Track Number, > >> Comment, Artist Name, Year, Genre" > >> > >> Unfortunately, if NAME, AUTH or ANNO contain an odd number of bytes, > >> then the file will fail completely in iPod Classics and show errors in > >> several applications, including> (Mac OS X) iTunes, Amadeus, Peak LE > >> and (Windows) Riff-Pad. > >> > >> The problem is that Audacity is correctly adding a padding byte when > >> necessary to make the number of bytes even, and correctly *not > >> including* that pad byte in ckSize, but iPod Classics and these > >> applications are incorrectly forgetting about the padding and looking > >> for the next chunk after ckSize bytes (thus the next chunk is offset > >> by one byte). > >> > >> Probably the easiest solution would be to not write the (optional) > >> Text chunks, but we would not want to do that if there are > >> applications that use those chunks. > >> > >> Steve > >> > > > > Hello Steve, > > > > i do not know the problem and i have no way for testing this but > > maybe that a simple solution would be to add a space character at the > > end of every even string rather than adding padding ? > > That extra space does allow the file to play on the problem iPod > concerned, and is allowable in the AIFF specification. > > Yes, I manually repaired a file that previously showed the problem by > replacing the padding and incrementing ckSize and that solved the > problem > > Given the bugs in old Mac apps, I don't know if adding a trailing space > could itself cause a problem. It's possible we could test that, given > time. > > iTunes itself has no problem in playing AIFF files where the optional > chunks have an odd number of bytes, and does not show any error > messages for them. > > Thanks for the clarification Gale, I was confused about that (you'll > understand why ;-) > > > iTunes deletes the optional chunks if you create > an AIFF version of the file, so that is the apparent workaround for > the problem. > > My guess is it would be too complicated to offer users a choice > of not exporting certain chunks (where the format exports more > than one chunk for a piece of metadata). > > An option to disable all metadata need not be confusing, and would > solve the problem of tracks not playing on the iPod Classic. All that > would be required in the interface is a checkbox in the metadata > editor. If it also greyed out the text fields in the editor then it > would be blindingly obvious. This would also be useful in other cases > where metadata is not wanted (it is all too easy for unwanted metadata > to slip into multi-track projects if audio is imported). > > Steve > > Yes I guess to limit a regression risk we could kill the optional chunks > only when encoding on Mac OS X. > > I noticed in Joel's patch that moves the LIST chunk to the end > and adds "PAD ", the optional chunks now appear at the bottom > of the file as well as at the top. > > Also that patch writes two SSND chunks if there is a LIST chunk. > I think that might be a problem, so I'll retest with the patch version > that does not duplicate the LIST chunk. > > > > > 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 > _______________________________________________ audacity-devel mailing > list aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel |
From: Steve t. F. <ste...@gm...> - 2013-08-14 15:07:18
|
Thanks for this Joel. It's not easy for me to test either as I don't have an iPod and I'm on Linux but I can look at the AIFF files in a hex editor and I have part time access to a Windows machine so I can test with Riff-Pad (slightly buggy freeware). It will probably take a while to get this properly tested as Koz is the only support team person that has an old iPod Classic and Gale is the only one that builds on Mac. Thanks Steve On 14 August 2013 13:13, Joel Bouchat <bo...@ho...> wrote: > Hello Steve, hello Gale, > > here is a patch wich adjusts the AIFF metadata chunks to even lengths > > I have added a space to the even length strings in such a way that the total length (including '\0' ending char) is also even. > This way the labels "NAME", "AUTH", "ANNO", are aligned on even addresses. > But, maybe that i have not well understood, maybe that this is the string length (without '\0') that must be even...? > Another question: in AIFF files, we are not obliged to install the Metadata at the end, we could as well let it at the beginning of the file, should i modify the code in this way? > ==> You will find attached at second patch which implements the AIFF tags in this way. > > I have no way for testing all this, foobar2000 doesn't recognize aiff metadata and i have no iPod and no MAC. > > Best regards, > > Joel > > ________________________________ >> Date: Tue, 13 Aug 2013 23:53:21 +0100 >> From: ste...@gm... >> To: aud...@li... >> Subject: Re: [Audacity-devel] Metadata in RIFF files (was: Back to >> ID3v2 metadata in WAV files) >> >> >> >> >> On 13 August 2013 22:05, Gale Andrews >> <ga...@au...<mailto:ga...@au...>> wrote: >> >> | From Joel Bouchat <bo...@ho...<mailto:bo...@ho...>> >> | Tue, 13 Aug 2013 22:05:50 +0200 >> | Subject: [Audacity-devel] Metadata in RIFF files (was: Back to ID3v2 >> metadata in WAV files) >> > Steve wrote: >> > >> > ---------------------------------------- >> >> Date: Tue, 13 Aug 2013 16:31:52 +0100 >> >> From: ste...@gm...<mailto:ste...@gm...> >> >> To: >> aud...@li...<mailto:aud...@li...> >> >> Subject: [Audacity-devel] Metadata in RIFF files (was: Back to >> ID3v2 metadata in WAV files) >> >> >> >> I've not been following this (Back to ID3v2 metadata in WAV files) >> >> thread closely as I don't generally use metadata, but as the topic is >> >> about changing the metadata in RIFF files I think it is relevant to >> >> mention an issue that has recently been identified on the Audacity >> >> forum concerning metadata in AIFF files. >> >> >> >> Currently Audacity includes "NAME", "AUTH", "ANNO" and "ID3 " chunks. >> >> "NAME" contains Audacity "Track Title" >> >> "AUTH" contains Audacity "Artist Name" >> >> "ANNO" contains Audacity "Comments" >> >> "ID3 " contains Audacity "Album Title, Track Title, Track Number, >> >> Comment, Artist Name, Year, Genre" >> >> >> >> Unfortunately, if NAME, AUTH or ANNO contain an odd number of bytes, >> >> then the file will fail completely in iPod Classics and show errors in >> >> several applications, including> (Mac OS X) iTunes, Amadeus, Peak LE >> >> and (Windows) Riff-Pad. >> >> >> >> The problem is that Audacity is correctly adding a padding byte when >> >> necessary to make the number of bytes even, and correctly *not >> >> including* that pad byte in ckSize, but iPod Classics and these >> >> applications are incorrectly forgetting about the padding and looking >> >> for the next chunk after ckSize bytes (thus the next chunk is offset >> >> by one byte). >> >> >> >> Probably the easiest solution would be to not write the (optional) >> >> Text chunks, but we would not want to do that if there are >> >> applications that use those chunks. >> >> >> >> Steve >> >> >> > >> > Hello Steve, >> > >> > i do not know the problem and i have no way for testing this but >> > maybe that a simple solution would be to add a space character at the >> > end of every even string rather than adding padding ? >> >> That extra space does allow the file to play on the problem iPod >> concerned, and is allowable in the AIFF specification. >> >> Yes, I manually repaired a file that previously showed the problem by >> replacing the padding and incrementing ckSize and that solved the >> problem >> >> Given the bugs in old Mac apps, I don't know if adding a trailing space >> could itself cause a problem. It's possible we could test that, given >> time. >> >> iTunes itself has no problem in playing AIFF files where the optional >> chunks have an odd number of bytes, and does not show any error >> messages for them. >> >> Thanks for the clarification Gale, I was confused about that (you'll >> understand why ;-) >> >> >> iTunes deletes the optional chunks if you create >> an AIFF version of the file, so that is the apparent workaround for >> the problem. >> >> My guess is it would be too complicated to offer users a choice >> of not exporting certain chunks (where the format exports more >> than one chunk for a piece of metadata). >> >> An option to disable all metadata need not be confusing, and would >> solve the problem of tracks not playing on the iPod Classic. All that >> would be required in the interface is a checkbox in the metadata >> editor. If it also greyed out the text fields in the editor then it >> would be blindingly obvious. This would also be useful in other cases >> where metadata is not wanted (it is all too easy for unwanted metadata >> to slip into multi-track projects if audio is imported). >> >> Steve >> >> Yes I guess to limit a regression risk we could kill the optional chunks >> only when encoding on Mac OS X. >> >> I noticed in Joel's patch that moves the LIST chunk to the end >> and adds "PAD ", the optional chunks now appear at the bottom >> of the file as well as at the top. >> >> Also that patch writes two SSND chunks if there is a LIST chunk. >> I think that might be a problem, so I'll retest with the patch version >> that does not duplicate the LIST chunk. >> >> >> >> >> 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 >> _______________________________________________ audacity-devel mailing >> list aud...@li... >> https://lists.sourceforge.net/lists/listinfo/audacity-devel > > ------------------------------------------------------------------------------ > 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: Joel B. <bo...@ho...> - 2013-08-14 18:48:03
|
Steve wrote > Thanks for this Joel. > > It's not easy for me to test either as I don't have an iPod and I'm on > Linux but I can look at the AIFF files in a hex editor and I have part > time access to a Windows machine so I can test with Riff-Pad (slightly > buggy freeware). It will probably take a while to get this properly > tested as Koz is the only support team person that has an old iPod > Classic and Gale is the only one that builds on Mac. > > Thanks > Steve ==> Hello Steve, I have downloaded RiffPad and i have checked some AIFF files... It seems that i have it all wrong! The Labels doesn't need to be aligned on even addresses, but the lengths of the strings must be even (in fact odd, with the added '\0'!). Here is the fixed patch. Best regards, Joel > > On 14 August 2013 13:13, Joel Bouchat <bo...@ho...> wrote: >> Hello Steve, hello Gale, >> >> here is a patch wich adjusts the AIFF metadata chunks to even lengths >> >> I have added a space to the even length strings in such a way that the total length (including '\0' ending char) is also even. >> This way the labels "NAME", "AUTH", "ANNO", are aligned on even addresses. >> But, maybe that i have not well understood, maybe that this is the string length (without '\0') that must be even...? >> Another question: in AIFF files, we are not obliged to install the Metadata at the end, we could as well let it at the beginning of the file, should i modify the code in this way? >> ==> You will find attached at second patch which implements the AIFF tags in this way. >> >> I have no way for testing all this, foobar2000 doesn't recognize aiff metadata and i have no iPod and no MAC. >> >> Best regards, >> >> Joel >> >> ________________________________ >>> Date: Tue, 13 Aug 2013 23:53:21 +0100 >>> From: ste...@gm... >>> To: aud...@li... >>> Subject: Re: [Audacity-devel] Metadata in RIFF files (was: Back to >>> ID3v2 metadata in WAV files) >>> >>> >>> >>> >>> On 13 August 2013 22:05, Gale Andrews >>> <ga...@au...<mailto:ga...@au...>> wrote: >>> >>> | From Joel Bouchat <bo...@ho...<mailto:bo...@ho...>> >>> | Tue, 13 Aug 2013 22:05:50 +0200 >>> | Subject: [Audacity-devel] Metadata in RIFF files (was: Back to ID3v2 >>> metadata in WAV files) >>>> Steve wrote: >>>> >>>> ---------------------------------------- >>>>> Date: Tue, 13 Aug 2013 16:31:52 +0100 >>>>> From: ste...@gm...<mailto:ste...@gm...> >>>>> To: >>> aud...@li...<mailto:aud...@li...> >>>>> Subject: [Audacity-devel] Metadata in RIFF files (was: Back to >>> ID3v2 metadata in WAV files) >>>>> >>>>> I've not been following this (Back to ID3v2 metadata in WAV files) >>>>> thread closely as I don't generally use metadata, but as the topic is >>>>> about changing the metadata in RIFF files I think it is relevant to >>>>> mention an issue that has recently been identified on the Audacity >>>>> forum concerning metadata in AIFF files. >>>>> >>>>> Currently Audacity includes "NAME", "AUTH", "ANNO" and "ID3 " chunks. >>>>> "NAME" contains Audacity "Track Title" >>>>> "AUTH" contains Audacity "Artist Name" >>>>> "ANNO" contains Audacity "Comments" >>>>> "ID3 " contains Audacity "Album Title, Track Title, Track Number, >>>>> Comment, Artist Name, Year, Genre" >>>>> >>>>> Unfortunately, if NAME, AUTH or ANNO contain an odd number of bytes, >>>>> then the file will fail completely in iPod Classics and show errors in >>>>> several applications, including> (Mac OS X) iTunes, Amadeus, Peak LE >>>>> and (Windows) Riff-Pad. >>>>> >>>>> The problem is that Audacity is correctly adding a padding byte when >>>>> necessary to make the number of bytes even, and correctly *not >>>>> including* that pad byte in ckSize, but iPod Classics and these >>>>> applications are incorrectly forgetting about the padding and looking >>>>> for the next chunk after ckSize bytes (thus the next chunk is offset >>>>> by one byte). >>>>> >>>>> Probably the easiest solution would be to not write the (optional) >>>>> Text chunks, but we would not want to do that if there are >>>>> applications that use those chunks. >>>>> >>>>> Steve >>>>> >>>> >>>> Hello Steve, >>>> >>>> i do not know the problem and i have no way for testing this but >>>> maybe that a simple solution would be to add a space character at the >>>> end of every even string rather than adding padding ? >>> >>> That extra space does allow the file to play on the problem iPod >>> concerned, and is allowable in the AIFF specification. >>> >>> Yes, I manually repaired a file that previously showed the problem by >>> replacing the padding and incrementing ckSize and that solved the >>> problem >>> >>> Given the bugs in old Mac apps, I don't know if adding a trailing space >>> could itself cause a problem. It's possible we could test that, given >>> time. >>> >>> iTunes itself has no problem in playing AIFF files where the optional >>> chunks have an odd number of bytes, and does not show any error >>> messages for them. >>> >>> Thanks for the clarification Gale, I was confused about that (you'll >>> understand why ;-) >>> >>> >>> iTunes deletes the optional chunks if you create >>> an AIFF version of the file, so that is the apparent workaround for >>> the problem. >>> >>> My guess is it would be too complicated to offer users a choice >>> of not exporting certain chunks (where the format exports more >>> than one chunk for a piece of metadata). >>> >>> An option to disable all metadata need not be confusing, and would >>> solve the problem of tracks not playing on the iPod Classic. All that >>> would be required in the interface is a checkbox in the metadata >>> editor. If it also greyed out the text fields in the editor then it >>> would be blindingly obvious. This would also be useful in other cases >>> where metadata is not wanted (it is all too easy for unwanted metadata >>> to slip into multi-track projects if audio is imported). >>> >>> Steve >>> >>> Yes I guess to limit a regression risk we could kill the optional chunks >>> only when encoding on Mac OS X. >>> >>> I noticed in Joel's patch that moves the LIST chunk to the end >>> and adds "PAD ", the optional chunks now appear at the bottom >>> of the file as well as at the top. >>> >>> Also that patch writes two SSND chunks if there is a LIST chunk. >>> I think that might be a problem, so I'll retest with the patch version >>> that does not duplicate the LIST chunk. >>> >>> >>> >>> >>> 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 >>> _______________________________________________ audacity-devel mailing >>> list aud...@li... >>> https://lists.sourceforge.net/lists/listinfo/audacity-devel >> >> ------------------------------------------------------------------------------ >> 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 >> > > ------------------------------------------------------------------------------ > 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 |