Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[memoryplayer]

Hi, any guidance on the following would be appreciated:

JRiver is not reading and extracting any metadata that has been previously stored as ID3 tags in the header in a w64 file. 

This tag appears to be stored in the header in exactly the same way for wav and w64 files, as its recognized as an ID3 tag for both file types by applications like dbpoweramp.  So what we want JRiver to do is simply use exactly the same mechanism to read and extract tags in w64 files that they currently use for reading and extracting tags in wav files. 

Without this, the problem we have is that tags on wav files that are converted to w64 are being maintained as they should, BUT the issue is that JRiver doesn't seem to be reading the tag, so all w64 files end up being imported with no metadata.  This doesn't happen with any other file type like wav, only with w64 files.  So we effectively lose all the tags we've applied to the files.   Meaning were left with the process of having to manually re-tag ALL the w64 files over again from scratch when the ID3 tag already exists correctly in the w64 header.

I'll try to post a specific example of this of a wav file with tags and then a version that's been converted to w64 file showing that the same ID3 tag exists in the header.but is lost in the import process.

Any guidance is appreciated.

[ferday]

Does it work if you rename the extension to .wav?

If you compress to flac do the tags fill?

I remember Matt saying they were working on it.  It's an unusual format, I don't think much can be done outside of the developers themselves

[memoryplayer]

Hi, thanks for the note.  I'll explore these questions and repost shortly.  Best,  Sam

[memoryplayer]

Hi, when we look at the ID Tags (using DBpoweramp), both the wav and W64 files show Artist,Title, Album, track, year and genre as per the photos shown below.  This suggests that there is some metadata that should be able to be imported into JRiver (other than by using the filename import).  Is this something that can be facilitated by JRiver from a programming standpoint?  If I import the file first as a wav and then as a w64, somehow JRiver seems to enable the w64 file to inherit the metadata from the wav even when the wav is first cleaned from the library.  Any guidance on this? 

Many thanks.

[axisjack]

Hi,

I'm new to JRiver and had the same issue, with existing tags on w64 files not being extracted during the import.  As I've got some 20,000 songs with ID3 tags (from their original wav or FLAC format, before being converted to w64) I couldn't afford to lose them all and start again.

 I could see the ID3 metadata using Dbpoweramp too, so I knew the tags existed in some form in the w64 file.

What I discovered through trial and error was the following workaround, that enabled me to extract the tags from the w64 file:

1)  Using the file rename / Copy function in Library Tools, I renamed all .w64 files to .wav.
2)  I then used the Update Library from Tags function, in JRiver Library Tools to read and extract the metadata from the wav file. 
** This step in mind proves that the tags are stored the same way in w64 and wav files, as when JRiver thinks its a wav file its reading, the tags are then able to be extracted correctly, as they would be for any genuine wav file.
3).  Rename the files back to w64 using JRiver Library Tools.

Now although this worked, in that the tags were imported from the renamed file into the JRiver database correctly, I have ended up with a follow on problem.  The issue I have is that even after renaming back to .w64 and being able to play the file sucessfully, JRiver is still displaying all these files as type wav, NOT w64.

So what I'd like confirmation on firstly its whether this means that JRiver is actually playing these files with the wav or w64 codec?  Does it go by the actual extension of the file on the OS (which is .w64) or the format as reported by JRiver (which is wav)?

Also, is there any way to update JRiver database so that these files are listed as w64 again, instead of wav?

As the process I used appears to validate that the tags are stored the same way in wav and w64 files, can one of the developers weight in here and confirm if support for w64 tag reading to populate the JRiver database is actually being worked on, or not? 

As they can be extracted the exact same way as a standard wav file, this should be very easy to do and would solve a major issue for anyone wanting to use w64 files with JRiver currently.  Having this functionality would avoid the messy workaround and the unfortunate follow on problem I've now got..

Any help would be much appreciated.

[JimH]

That's the first time I had ever heard of a .w64 file.  I had to look it up.

It's Sony's special version of a wav file, first introduced by Soundforge as a way around a limit of 2GB for WAV.

We'll take a look at the problem.

[Matt]

Could you send a sample of one of the files to matt at jriver dot com?

Looking at our code we read w64 files in our WAV plugin.  It has ID3 code.  It looks for a chunk named ID3 or tag, and then reads the tag if it finds it.