View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0005144 | MMW v4 | Framework: Tagging | public | 2009-01-06 20:43 | 2010-02-12 14:49 |
Reporter | rusty | Assigned To | |||
Priority | immediate | Severity | major | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 3.1 | ||||
Fixed in Version | 3.1 | ||||
Summary | 0005144: Problems reading wav tags from SoundMiner | ||||
Description | Please have a look at this. A customer is having problems with this issue, and I'm not sure whether this is easily fixable or not. Tags appear like this when scanned by MM: ÿþG:o:o:d: :K:i:n:g: :P:o:p: :R:o:c:k: They should appear as: Good King Pop Rock To read the tags properly, you can use dbpoweramp. | ||||
Additional Information | Original report at: http://www.mediamonkey.com/support/staff/index.php?_m=tickets&_a=viewticket&ticketid=3258 Tracks are posted to the ftp server. | ||||
Tags | No tags attached. | ||||
Fixed in build | 1221 | ||||
|
After brief look WAVE files saved in soundminer contain additional extended tag format http://hul.harvard.edu/jhove/wave-hul.html Broadcast Wave Format and file native extension should be .BWF to clearly state that Audio Data is preserved in WAVE format Tag Data and its handling should be handled according to Broadcast Wave Format (BWF) |
|
In order of priority: 1) Be able to read standard riff data correctly from SoundMiner 2) Be able to read custom tags from Soundminer 3) Be able to write custom tags for Soundminer Items 2 and 3 are clearly out of scope for MM 3.1. Item 1 would be nice to have if it's an easy/low risk fix. |
|
1) Currently MMs TNT components can't read/translate Unicode Written Tags in SoundMiner, but instead of trying to translate/read Unicode it should use second set of RIFF Tags that are normally written in ASCII 2), 3) we would need to get exact spec of field relations used in SoundMiner for better implementation |
|
Fixed in build 1219. - I simply fixed reading of ID3 tag that's present in WAV file and now it's ok. |
|
Confirmed 1219 that ID3 Tags written in UTF-16 are now read correctly |
|
Internal Soundminer .BWF format is still not read should we add it? |
|
I don't think that we need to support any application specific format. |
|
I have a batch of wav tracks of which many are not being read correctly. Will upload to ftp. |
|
There doesn't seem to be any problem on MM side. On the tracks I have checked, there was one chunk 1 byte shorter than it should be, which caused that further chunks aren't scanned by MM (they simply can't be) and so correct metadata present in the tracks can't be read. |
|
Assigned to Rusty to verify the source of the corruption / what kind of similar corruptions we can expect and determine whether MM should add some heuristics to get around the problem that the tags are inaccessible since chunk link is corrupted before MM reaches them. |
|
When you check this please note that due the fact that RIFF tag chunks are not standardized like for example in FLAC where Author said that usage of ID3v2 is possible but highly disapproved and should be either ignored/cleaned and not supported. Currently each chunk is checked for valid format and assumed read info is correct. It is one of the oldest plugins made for MM it should be revised especially as .AVI uses same tag/chunk format. Additionally WAV now support Multi Channels (5.1, 7.1 and 24, 32 and 64 Bit audio data along with 192Khz bitrate) In last few revisions Jiri corrected JUNK chunk Correction (It posed high risk especially on network environment due the high number of access and brute force changes to speed processing on large files). Your non subjective revision is highly recommended. |
|
Re-assigning to Jiri. Further testing shows that the tracks are correctly read by Windows Media Player as well as a couple of other apps?! |
|
Fixed in build 1221. - There was some old thing in the plug-in that wasn't according to the spec. |
|
Verified 1233 |