Start a new topic

Showing and Editing Wrong Tracks (Make in Untrustable)

my Ver is 12.3
Sometimes I see Software show wrong Data for some music
for Example
an Album have 2 Song, A and B
I Tag these two with A and B
But after a while, when I come back and play A, i hear B and B for A
Wrong Data, it make software unreliable and untranslatable
I go back to Ver.11 until next update

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?

that's not an issue that happen all the time, but once is all there is need to make software unreliable
1-Format is MP3
2-i'm not sure what you mean by DB, but i use ID3V1 and ID3V2
and i added and tagged this tracks to helium 12.0
and then updated it to 12.3
this problem is not the first time that happened, i have experimented in V12.0 too
I'm not so good on these things to help you that much
but this may be because Helium 12 is designed for Win10 and not 7
or maybe there is some issue with Runtime i installed and what is starndard for you
I only can make you more clear the situation
I uploaded 2 photo for you
white one is from V11 and black V12
you can see that the filenames and tags are not matched
right few minute ago, i saw two album that was in same folder and the info for this two album were reverse of each other, info for Album A for B and reverse
I just opened 20 Album in helium 11 and half of those have switched info for all tags like artist composer conductor and so on
MP3Tag confirm helium 11
right now, i can't trust helium 12 anymore


(70.6 KB)
(116 KB)

(Case reopened)

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.

as you can see, it seems i have many problems with H12.3
are these problems because of using Win7 or a wrong version of .NET
mean the problem is not from H12.3, but some other place
I'll be happy to send you Video if it needed

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.

OK if you have no luck I'll send db backup along with the album folder via a support ticket.
my windows is Win7 64bit
and this is not what always happen
also many other features in helium 12 are not working right
i refer it to a problem in .NET
because some other program have problem to install because of .NET
and helium is based on .NET too

as you can see here, I can fix the wrong tags with a little effort


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.

I had many problems with my Helium12
turns out that my Win7 was not SP1
after I installed SP1 and my more updates
"move", "copy" and many other features start to working
but this "Wrong Tag Bug" is still remaining

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:

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?

@Digiraiter Agumon:

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.

I've ran into this issue now, too...

The filename is correct, but the tags are completely wrong...

That's a very bad issue - since I could have lost many information in this case, luckily I've seen this nearly immediately, so I can easily go back to a correct state.
Login or Signup to post a comment