Thanks for the video Carl.Very good input!
I will directly try to see if I can reproduce this. (I tested with a single CD album, where everything worked)
Another thing that would be really great if you could test is to:
1) Create a new database (SqlCompact is fine)
2) Add this album to the new database
3) Perform the same tagging
Will this reproduce the problem?
I tried to reproduce this issue with a similar folder setup (I think) but during my test it worked. Please see this video:
If you can reproduce it with a clean database as asked for above, I suspect that it *might* depend on either/or a combination of your folder structure (full path to the album files) or the existing tags on the files.
Therefore it would be great depending on your result if ou can share your full path of the album files with us together with the files so that we can perform a detailed analysis of your data.
I would if so recommend you to share the files with us over a support ticket to avoid sharing them in public.
Ok Made new database with sqlcompact with same album. Artist/ all tracks select both cds edit tags etc save and eveything as it should be....all ok :) Back in to artist/album view and still showing as two separate cds. So multi select both albums. List comes up ok but although track names and numbers are correct they are out of order so order by cd number then hold shift and select track order. Now everthing is correct tag name, tag track number and tag cd number. Select ok and it cross tagged all the files again???? very strange.
Ok, thanks. Possibly this might be related to some existing data in your database then in combination with existing tag data?
What we then can do is then that you create a backup of your database and share with us together with the files when in the video.
We can then restore the database and perform the exact same tagging test to see which result we will get.
Would it be possible if you share these files with us?
Thanks in advance.
M:\My Music\Nightwish\Dark_Passion_Play-2007-[japan edition]l\CD 2 (versión Instrumental)\201-nightwish-the_poet_and_the_pendulum.mp3
M:\My Music\Nightwish\Dark_Passion_Play-2007-[japan edition]l\CD 1\01_-_Poet_and_the_Pendulum.mp3
folder structure for cd1 and 2.. I see where you're coming from but files been there for as long as i remember.
Thanks. I will set up this folder structure with a test album to see which result I get.
I still think that it is database/tag related though, but I will report my results soon.
I have now performed the test with two different albums using the described album structure, using a SqlCompact database.
These tests works as expected, e.g. no offset errors occured.
Therefore it would be realy great if you can share your database and files with us so that we can continue to test this.
Big thanks in advance.
One more correction for this is now available (an early pre-release version).
Sven identified a case where this could happen so it is now corected.
If anyone need access to this version, please contact us via: http://support.imploded.com
It shall also handle cases with "bad/incorrect" tags
We have tried to reproduce this as described, unfortunately with no luck. In the end it somehow seemed system related to the users configuration.
When you perform a tagging operation in Helium, the following logic is applied:
1) Based on which view you are working with a selection of files will be created;
Working with a tracklist will simply open the selected files as it looks in the current view - the sorting from that view will be used.
Selecting an album for tagging will first get a list of the files involved in the album and then open the Tag editor with this list.
For files that are added to your library, Helium will store a list where the key of an item is the database id of the track and this id is mapped to the full path and filename.
2) When the Tag editor is opened files are loaded and tags are read for all files, based on their filename. If you select an entry in the Tag editor, you can see at the top which exact file you are working with.
3) When you are done with the tagging and click OK the following will happen:
-Changes for each item will be stored in a cache. Each cache entry is mapped to the full filename in the list generated in step 1.
-For files that exists in your library the database data will be updated. To update the correct item, the database id, as stored in the in-memory list described in step 1, will be used to locate the entry. This entry is still mapped to the full filename of the track (this list is read-only, immutable). For files not in the library (tagging from the My Computer view for example) this step will be skipped.
-When the above is completed, a background operation will be invoked where each cache entry will be applied to files (the actual tag writing).
With all the above logic, we have performed multiple tests to ensure that the proper tags were written to the proper files.
The validation has been performed both manually by inspecting a files tag contents after tagging as well as via reviewing logs.
No issues were found during our tests. All tests were performed with both MP3 and FLAC files, using a Windows 10 machine with MariaDB and SqlCompact.
Which view did you used when the issue occured? (e.g. Releases, My Computer etc)
Was the files available in your database? (If you are using the My Computer view you can work with tracks not added to your database)
Any additional information (screenshot, example files etc) are welcome so that we can analyse this further.
Possibly we have missed some step during our tests that you included in your tests?
What your YouTube video shows does not relate to incorrect tagging, it relates to a clipboard problem.
We have answered you via the support ticket you reported related to this and requested one or two example files containing these japaneese characters that generated your clipboard issue.
If anyone else have noticed any oddities related to the possible tagging problem mentioned, please let us know.
Any additional reproduction details are welcome since we have unfortunately not been able to reproduce it.
The filename is correct, but the tags are completely wrong...