Managing a huge digital collection

It seems that ripped cds have volumes of fields to modify while hi-def files have just a few. Tag Scanner 3.1 doesn't seem to provide me any means to get non-original fields to display at least in my UnitiServe Naim app. Has anyone found a way through this restriction?

What are the specific fields that TagScanner doesn't display/edit?

Tagscanner 3.1 is rather old.  The latest is 5.1 but that doesn't appear to offer a means of customizing the list of fields available for editing either. Try Mp3tag, which does.

I'm glad I am not the only one who does this...sometimes I think I am losing my mind as I get older!

I fing the discussion of tagging WAV files odd.  WAV files are a subset of Resource Interchange File Format (RIFF), which is a Microsoft proprietary standard and has no chunk definition that can be used for ID3 tags.  Therefore WAV files cannot legitimately have tags.

A tag structure can be inserted into the file, but even if it has a .wav file extension it then doesn't comply with the RIFF so technically it's no longer a WAV formatted file.

As a result of this there's no guarantee that it will work with any specific programme or piece of equipment.  It's up to the whim of the designer as to whether they support your particular non-standard way of inserting tag information.  Indeed the whole file may legitimately be deemed unreadable.

If you have all your equipment and applications from one manufacturer one hopes it will work (e.g. Naim Unitiserve / Naim streamer / nStream), but mix and match and you're on your own, it may or may not work.  There's no point in complaining if it doesn't.

This is the advantage that Uncompressed FLAC has.  The ID3 tags are part of the standard definition and it contains the same LPCM data as the WAV file.

Do these allow the tags to be altered?  If so which one works well?

My library is quite up together now but I would like to be able to make small corrections as I find them whilst listening from the iPad.  This is something our UnitiServe friends take for granted.

RIchard

I just tried MMWI add and it doesn't allow editing of the tracks/files. You can play and create playlists etc... but that's about it.

Sorry for the above. Well Tag Scanner has many fields, for instance, conductor. However my IPAD Naim App for UnitiServe will not display it. This is true for my hi-def files.

Huge, I am afraid I disagree with you there. The IFF format (from Electronic Arts) format was used by both Microsoft and Apple to create WAV files and AIFF files. They are essentially the same RIFF construct.

The RIFF file was developed originally for general purpose mutimedia, not just audio, and so has a fairly extensive  incorporated construct (chunk)'for meta data. It is contained within the INFO list construct (chunk) within the RIFF file. It's draw back is that it is not specific to recorded album audio, and certain fields are open to differing interpretations for album audio. As far as i can see INFO list was never incoporated into AIF.

WAV was developed as a subset of RIFF specifically for audio - and had two formats - a simple 'canonical format' and a later 'extensible format'. One key difference is the latter allowed multichannel and reliable hidef amongst other things

Later on ID3 tags came along which were optimised for album music / tracks and were formally added into the AIF format as a new registered chunk.

The WAV format is essentially open, and so private extensions can be legitimately added. iD3 tags have been added, but were not part of the common standard such as INFO list.

Therefore these days some software supports both WAV meta data constructs, INFO list and ID3. The RIFF format allows this of course.

Early multimedia software however only processed WAV INFO list, and of course Apple don't recognise any WAV RIFF construct other than HEADER and DATA chunks... Not very helpful! I can only assume this is because of where WAV comes from. WAVs extensive flexibility has probably ultimately caused some confusion in its adoption and use. Reading the web, there is a lot of misinformation pertaining to WAV and meta data.

A valid WAV file, just like AIF file need only have a HEADER and DATA RIFF chunk to be valid, which clearly excludes meta data. 

So WAV file can legitimately have tags. 

Simon

PS FLAC as standard files do not support ID3,tags, they use a seperate meta data construct called 'Vorbis comments'. 

OK, now I understand. So the problem is with the Naim App, not TagScanner. I think most apps like that (including nStream) don't let you customize the fields and display the more exotic ones, because for 99% of customers the usual suspects like Artist, Album, etc. are good enough...

One field I was greatly hoping the new Naim App would display was the "Lyrics" field Alas, no, unless I missed something, I'm still learning how to use the new App.

Actually, I believe the problem is with the server software rather than the app.  I say this because I'm using the naim app with a NAS running Minimserver.  The app allows me to browse to Conductor and Orchestra if I wish.  This is because Minimserver is designed with classical music lovers in mind.  The Twonky server can also be customized to operate with any tags that you fancy by designing an appropriate tree structure to accommodate them.

Oh, I see. I think my Synology's native Multimedia Server doesn't allow browsing by e.g. Orchestra, either. I understand Minimserver does, but unfortunately I'm too stupid for Minimserver - I spent quite some time trying to understand its settings and its manual, then gave up.

Yes, the Minimserver manual is daunting, but in practice, once you have managed to install it, there's very little to do other than tell it where your music library is located. I have found it to be quite trouble free and my nice little 1TB QNAP NAS runs for weeks on end without attention.

Hi Simon,

I agree there is a lot of misinformation about the Microsoft WAVE file format, that's why I read the MSDN articles.  Microsoft own the definition of the file, and MSDN is their public documentation.

I would agree with your conclusion in respect of IFF (as you say that was from Electronic Arts) but WAVE is defined in a much more limited way.  The only permitted chunk codes are:

"RIFF", "fmt", "data", "smpl", "wsmpl"

none of which can contain metadata (other than that to do with the file structure and data format(s)).

It would be entirely appropriate for a WAVE file rendered to terminate read on encountering anything else, on the grounds that

1  it's a format error

2  it may be malicious

This would cause it to correctly reject a WAVE file that contained ID3 tags.

If I were reviewing code to read a WAVE file and it read the ID3 tags, then as the chunk is non-standard I'd require substantial format verification to not only ensure the data are well formed XML but, more importantly, require proof that no buffer overruns, command execution exploits or other vulnerabilities were possible.  Without this proof I'd reject the code as unsafe.

Incidentally a BWF (another extension of IFF) renderers will correctly render WAVE files as BWF definitions for the "RIFF", "fmt", "data" include all those those defined for WAVE.  This is not true the other way round.

It's also the case that a WAVE renderer can't necessarily render AIFF despite them both being IFF file formats.

P.S. Yes I forgot to switch my mind back to Vorbis when commenting about Uncompressed FLAC, but the argument in it's favour still stands (even though the Vorbis comment structure is even weaker than ID3!).

I'm sorry, I have to strongly disagree with that statement - your posts on this forum argue against that conclusion and your English is so much better than my Polish (and even vodka won't help me with that!).

Huge

Please find the RIFF and WAV extensions for RIFF as defined by IBM and Microsoft.

WAV was simply the audio wave form version of RIFF.

http://www-mmsp.ece.mcgill.ca/...rmats/WAVE/WAVE.html

Over the years commercially I have  used WAV files using INFO list as described as a valid RIFF construct for WAV for the definition of meta data. I have used these sort of WAV files for IVR prompts in ACDs and MoH applications.

In multimedia applications Cue points are quite a common chunk to use in WAVE files as well.

There is also a tiny subset of Wave files called the canonical wave file - and these are simplified files typically only contain a FMT and DATA chunks within the WAVE RIFF. These are intended for 16 bit only audio and maximum of two channel.

A canonical WAVE parser can read a full WAVE file as the RIFF standard requires unknown chunks to be ignored.

BTW I think MS Windows parses WAVE info List in file explorer and presents the meta data - but does not parse ID3 unless you sue a 3rd party extension. On a WAVE file go to Right mouse click - Properties/Details and List Info meta data is shown I believe if present in the WAVE file

Simon

Hi Simon,

From the horse's mouth:

http://msdn.microsoft.com/en-g...13%28v=vs.85%29.aspx

This is the definition for WAVE files for the DirectX Audio section of MSDN.

Huge - I get page not found - but WAVE is essentially a defacto standard now - perhaps MS have created a subset for their own use now. The WAVE standard does not preclude that !! Its one of the powerful feature of the RIFF structure.

But as I say MS do support list info leta data chunks in their OS - as I have just tried it..so what do you make of that?

Also I have just searched on MS and found the audio RIFF format for WAVE for XAudio2 and it defines the minimum subset of chunks - and allows other RIFF chunks to be added appropriate for the media - as discussed above. Unfortunately I cant post that link....

Simon

 Hi Simon,

I hadn't seen that the page did an immediate client side redirection (<0.5 seconds on my system)

This should work

http://www.google.co.uk/url?sa...vm=bv.80642063,d.ZGU

It's the definition for the valid Audio formats for DirectX (based on RIFF). i.e. the WAVE format(s).  It makes no provision for other chunk types.

WAVE is a de-facto standard, but a de-facto standard that is OWNED by Microsoft.  It should be noted that WAVE is built on RIFF, but that doesn't imply that WAVE has to support all the provisions of RIFF.  The WAVE format is defined by Microsoft (as the owner).  Other people may add other elements as the base RIFF is extensible, but these extensions are not part of the WAVE file format definition.  Files containing these are therefore, by definition non-standard, and not formally compliant with the WAVE file format definition.

That any particular renderer or file utility can read these extra data chunks types is immaterial.  Incidentally, there are numerous instances where Microsoft code breaks their own rules - that proves nothing.

I agree that ID3 tags are acceptable in RIFF files, they're just not in the standard for WAVE files; hence files that contain them don't comply with the WAVE file format definition.

As I said, that any particular renderer or tool can or cannot read them or use that additional information is immaterial, they don't have to and can still be fully compliant with the WAVE file format whichever way.  A tool that writes these extra chunks when writing a WAVE file is NOT compliant with the WAVE file format.

Maybe it's just me but I get considerable 'well being' feelings from grooming my ripped audio and video collection ... at the last count it was running at 27Tb!

I ended up just changing all my "A ..." and "The ..." to "..., A" and "..., The", making sure all multi CD albums were named as "... [CD 1]" onwards (rather than "... (CD 2)" and the first disc not numbered)

Phil

You are too kind! OK, let's just say that my brain and thatof the MinimServer author are not compatible And if you ever happen to be in Warsaw, you are hereby invited for a glass of vodka and a Polish lesson.

I agree, once it works, it works, although I would like to be able to go from AlbumArtist right into the list of Albums in the Naim App, instead of being presented first with a screen that tells me a given AlbumArtist has X albums, X songs, etc... If I could achieve that, I would probably start using MinimServer exclusively, because, for once, it scans the NAS in a fraction of the time it takes Synology Multimedia Server. I think the album graphics download faster from MinimServer, too.

Huge, we will have to agree to disagree on this one - most days I deal with compliant WAVE files that have standardised and private RIFF chunk types and they ARE completely valid - and indeed MS say on their current XAudio2 RIFF specifications for WAVE that different chunk types can be used pertaining to the audio type in the DATA chunk, but expect a common subset for all data types.

Simon

http://msdn.microsoft.com/en-g...ows/desktop/ee415713

Simon, I think the difference of opinion comes from our backgrounds

You as a consumer and/or creator of these files

Me as a systems programmer and designer and a code security expert

I still see no way that document allows anything in the 'data' chunks other than audio signal data.

I am using this as well- as I have specific desires around how I represent my collection. Yes it was a lot of work - but I am now in perfect condition.