Tags not working for .wav files

[marble-sh]

I'm not sure if I have configured it correctly but deadbeef seems incapable of reading tags of .wav files. .mp3 files work just fine though.

DeaDBeeF 0.6.2

mediainfo 01\ Modest\ Mouse\ -\ Strangers\ to\ Ourselves.wav

General
Complete name                            : 01 Modest Mouse - Strangers to Ourselves.wav
Format                                   : Wave
File size                                : 34.4 MiB
Duration                                 : 3mn 24s
Overall bit rate mode                    : Constant
Overall bit rate                         : 1 411 Kbps
Album                                    : Strangers to Ourselves
Album/Performer                          : Modest Mouse
Track name                               : Strangers to Ourselves
Track name/Position                      : 1
Track name/Total                         : 15
Performer                                : Modest Mouse
Composer                                 : Modest Mouse
Director                                 : Modest Mouse
Genre                                    : Alternative Rock
Recorded date                            : 2015-03-13
...

Audio
Format                                   : PCM
Format settings, Endianness              : Little
Format settings, Sign                    : Signed
Codec ID                                 : 1
Duration                                 : 3mn 24s
Bit rate mode                            : Constant
Bit rate                                 : 1 411.2 Kbps
Channel(s)                               : 2 channels
Sampling rate                            : 44.1 KHz
Bit depth                                : 16 bits
Stream size                              : 34.4 MiB (100%)

[Oleksiy-Yakovenko]

What tag format do you use for tagging the wav files? Or which tagging tool?

[marble-sh]

The files were ripped directly from CD using XLD, which queries freedb.freedb.org for tags. The tag file format appears to be RIFF.

hexdump -C 01\ Modest\ Mouse\ -\ Strangers\ to\ Ourselves.wav | head -3
00000000  52 49 46 46 9c 67 26 02  57 41 56 45 66 6d 74 20  |RIFF.g&.WAVEfmt |
00000010  10 00 00 00 01 00 02 00  44 ac 00 00 10 b1 02 00  |........D.......|
00000020  04 00 10 00 4c 49 53 54  68 00 00 00 49 4e 46 4f  |....LISTh...INFO|

[Oleksiy-Yakovenko]

Thanks for the XLD link, I'll give it a shot.

[kode54]

There is another tag format for RIFF files as well, the "id3 " (69643320) chunk, which contains an ID3v2 tag. Several editors also support this format and also store RIFF INFO chunks for compatibility. foobar2000 also reads and writes these ID3v2 chunks.

[kode54]

If nobody else looks into this one, I may give it a shot. I don't know how much work the RIFF LIST->INFO chunk will be, but I know the "id3 " chunk will only require calling the player's existing ID3v2 tag reader, hopefully. Writing will require a little more work, since it will require restructuring the files a bit. The easiest way to restructure is to put the tags on the end of the file, and rewrite them on changes. If they're somehow at the head of the file, then they can be replaced with junk padding chunks.

[Oleksiy-Yakovenko]

@kode54 libsndfile seems to support both reading and writing some sort of WAV/AIFF metadata.

http://www.mega-nerd.com/libsndfile/api.html#string

So adding this should be relatively easy.

Regarding id3, I don't like the idea of making your own WAV muxer just for that. Not that it's difficult, just a lot of duplicate code for a small thing. Libsndfile has all code necessary for that, just doesn't provide an API for working with chunks directly. sigh. While forking the libsndfile and adding such feature should not be difficult, another forked lib in the codebase is a hassle.

[xinyazhang]

So adding this should be relatively easy.

Unfortunately sf_get_string is not the end of the story. sf_get_string actually does not read the id3 chunk in .wav files. Instead its only data sources are riff/wave chunks (see wavlike_subchunk_parse function at wavlike.c)

This usually works okay, but sometimes the ID3 chunk contains more things like album cover. In this case we need to parse the ID3 chunk to get all the information.

However there is a problem when parsing the ID3 chunk with current infrastructure. The junklib always rewinds to the beginning of the file before reading any data to parse, but clearly the ID3 chunk in .wav files are not at the beginning.

There are a few choices in my mind:

1. Implement yet another vfs called memfile://, so we can copy the ID3 chunk data to the memfile and let junklib parse.
2. Modify deadbeef.h API and add junk_id3v2_read_mem, junk_id3v2_read_full_mem like APEv2 tags.
3. Do not rewind in junklib API and let the caller do the rewind (this may break things).

I personally prefer the first approach (orthogonal to existing functions, maybe useful for other cases). Any comments?

[Oleksiy-Yakovenko]

I think, to make it work correctly/properly, we would need to add riff/wav support to junklib, and be able to identify the right id3v2 chunks, and be able to write them back. This is not easy, but perhaps there's some open-source library that can help.

If you're aiming to make it read only, and without album art support -- it's as simple as adding a new API, with a minor change to avoid rewind.

[xinyazhang]

If you're aiming to make it read only, and without album art support -- it's as simple as adding a new API, with a minor change to avoid rewind.

I just realized one thing, libsndfile does not expose the offsets of RIFF chunks in the file. So no rewinding won't solve the problem because the only choice left is to parse the blobs from sf_get_chunk_data -- unless we'd like to parse the .wav file directly.

[xinyazhang]

@Alexey-Yakovenko I tried some changes to let sndfile plugin read id3 tags without changing the API, but there are still some problems left.

1. chunk related functions were introduced in libsndfile 1.0.26, but Ubuntu 14.04's version is exactly one release older, so the CI always fails with current changes. Furthermore, libsndfile doesn't have Macros to indicate its version, and thus we have no easy way to disable it during compiling.
2. To handle cover art this memfile related things must be shared with artwork plugin. Maybe this function really needs to be put into junklib, but that also pull hard dependency of libsndfile to the main code.