Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Resurrecting/Preserving the Helix MP3 encoder (Read 44335 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #100 –
Quote from: maikmerten on
This might actually warrant rolling back to writing "Xing" in the header, even for CBR files. fb2k might be fixable, but Windows isn't.
That would be the quicker fix, I guess. Lame writes a full size Xing/Info tag even for CBR files and everything reads it correctly. I've been trying to figure out where the hmp3 tag writing differs that causes the issue. Clearly the lame written tag includes more info as it was designed for lame and the hmp3 code either doesn't generate the same information, or doesn't use the same functions/variables, but I believe there must be some other fundamental point that I'm missing! I will continue to try to find it!!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #101 –
Quote from: john33 on
That would be the quicker fix, I guess. Lame writes a full size Xing/Info tag even for CBR files and everything reads it correctly. I've been trying to figure out where the hmp3 tag writing differs that causes the issue. Clearly the lame written tag includes more info as it was designed for lame and the hmp3 code either doesn't generate the same information, or doesn't use the same functions/variables, but I believe there must be some other fundamental point that I'm missing! I will continue to try to find it!!

Hmmm... one thing I did change: If the file is CBR, I do not include the the Xing VBR Table of Contents (TOC). This makes the header smaller and thus fits into more CBR frame sizes. What happens if you comment out lines 241 and 242 in xhead.c?

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #102 –
Thanks for all the explanations.
Please carry on  :)

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #103 –
Quote from: maikmerten on
Hmmm... one thing I did change: If the file is CBR, I do not include the the Xing VBR Table of Contents (TOC). This makes the header smaller and thus fits into more CBR frame sizes. What happens if you comment out lines 241 and 242 in xhead.c?
If I leave the header as 'Xing' and re-enable the TOC, all is OK except that fb2k calls it VBR. Lametag 0.3.1 recogises the tag as expected. If I then change the header to 'Info', all is good except that Windows now ignores the delay/padding, but Lametag 0.3.1 still reads the tag correctly. I know Windows is a law unto itself but since the lame 'Info' tag is read correctly by Windows, there must be something included in the lame written tag that is missing from the hmp3 written tag that is important to Windows. The question is, what?!?!

Edit: On reflection, I think it likely that Windows is probably expecting one, or more, positions in the tag to be filled with data that hmp3 doesn't generate, or can't fill because the encoder internals are different and the data isn't available in a suitable format. Unless someone has a bright idea, it's probably simpler to use the 'Xing' tag + TOC and perhaps Peter can tweak fb2k to see it as CBR, or otherwise just live with it.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #104 –
Okay, I think I got this fixed.

Turns out that for CBR the size of the first frame (where the info tag is stored) was only half of what it was supposed to be - because in the Helix MP3 encoder, the bitrate is set *per channel*, but I forgot to multiply the bitrate by the number of channels.

Thus "CBR" files were not _actually_ CBR, because the first frame was smaller than the rest. This most likely lead fb2k to say "VBR" (not all frames are of equal size), and I guess Windows got confused as well.

I now also write the TOC into CBR files, unless the bitrate is very low.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #105 –
Ladies and Gentlemen, I believe we have a winner! This now appears to meet all demands. Should we bump to 5.2.1 as this is not an insignificant fix?

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #106 –
I don't think we should burn through the version numbers quite that quickly, as I don't assume anyone really mass-encoded with the daily builds ;-)

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #107 –
Rarewares compile updated. :)

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #108 –
Thanks!

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #109 –
Thank you, experts, for further improving such a legacy MP3 encoder!

Over the past years i used mp3guessenc for analyzing MP3s. This tool also verifies the LAME tag in some way. This "Tag verification" check fails with the hmp3 encoder.
Could this also be relevant, referring to the prior compatibility discussions? I'm not a developer, so I'm not that experienced in reading source codes to find an answer myself.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #110 –
lametag 0.3.1 reads the tag fine, but 0.4.1 does not. I can't speak for mp3guessenc, but I suspect it depends on how specific the software is in needing lame specific information. It could even be that it fails because the version characters of the lametag are not 3.xxx, but I am only guessing. Without knowing the specific determing factors that mp3guessenc uses, further comment is irrelevant.

However, lame decodes hmp3 encoded files correctly, so I would believe that it's a software problem rather than a 'tagging' problem.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #111 –
Hello,

I don't know if it has already been reported: tag part of tagged WAV files is encoded as if it was PCM.

    AiZ

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #112 –
Quote from: AiZ on
Hello,

I don't know if it has already been reported: tag part of tagged WAV files is encoded as if it was PCM.

    AiZ
I presume you are taking about id3 tagged wav files which may be so, but then wav files shouldn't be id3 tagged in the first place.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #113 –
Hi John,

Quote from: john33 on
I presume you are taking about id3 tagged wav files which may be so, but then wav files shouldn't be id3 tagged in the first place.

You're right, problems come with id3 tags, RIFF tags are Ok.

    AiZ

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #114 –
Quote from: 145dBSPL on
Over the past years i used mp3guessenc for analyzing MP3s. This tool also verifies the LAME tag in some way. This "Tag verification" check fails with the hmp3 encoder.

Oh, that's perfectly expected. The info tag has fields for 16-bit checksums (tag checksum, MP3 checksum). Those fields are currently left "empty" (filled with zeros), so there's no checksum information to check against.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #116 –
Thank you for your explanations, John and maikmerten.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #117 –
Maybe it's just me, but it seems like the correct tagging approach should be to write HELIX instead of LAME, and then have other programs like foobar2000 update to support the existence of multiple MP3 encoders, rather than writing "LAMEH" or similar by default to trick other programs into thinking LAME was used.

There ought to be a switch to enable this behaviour if you need your MP3s to work on some old software that will never get updated, but the fact that other software developers have required the string "LAME" in the tag seems to me like their problem, not yours, and it would be better if they updated their programs, rather than you being forced to use hacks by default in yours.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #118 –
fb2k plays and decodes correctly with a 'HELIX5.20' header, as do some other players, and lame decodes such a file correctly. The versions of lametag that I have fail to read the tag with the Helix header and the chances are that there are many pieces of software in use that will fail at some level where the chances of the necessary changes being implemented are negligable. So, although I agree with you philosophically, pragmatically it is probably better to stick with what it is currently.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #119 –
The problem really is that there is little development interest in MP3 these days. I don't expect a lot of playback software to get updated to read something like "HELIX5.20" properly (which I'd prefer, of course). This might lead to some user frustration with, e.g., gapless playback not working properly and updates needing months or years to tickle down to users.

Also note that "LAMEH5.20" includes all the information necessary to identify it as a Helix file - if there's a "H", it's Helix.

This is very much like LAME having to write "Xing" into the info header for players to recognize the Xing-VBR tag, despite not being Xing, obviously. We've now come full-circle, with LAME using "Xing" and Xing/Helix using a "LAME"-prefix.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #120 –
Quote from: maikmerten on
We've now come full-circle, with LAME using "Xing" and Xing/Helix using a "LAME"-prefix.
Mathie: "Two wrongs don't make a right!"
Engineer: "If it makes a workable ...?"
Patching up lossy codecs' old sins falls into the engineering category. Go ahead with it if it works.

There is an aside here: Back in the day when Xing was called Xing, did other encoders write headers such that (later?) tool would (mis-)identify them as "Xing" encodes? Anyone remembering them early days of the industrial revolution? :)


Reason why I am asking is that - although I don't remember twenty-five year old artifacts and that kind of thing, I remember that "Xing-identified" files could be quite crappy. But that impression may also have stuck out of all the things people did back then, like for example "merging MP3s by concatenating the files". Hey if there were no tags, it wouldn't be too bad, at least not when MP3s wouldn't be completely gapless anyway. And if there only was an ID3v1 ...
But if there were other "worse" (audio quality or header implementation!) codecs that would identify or be mis-identified as "Xing", and would later die out ... would explain something.
 

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #121 –
Well, Xing had a VBR header SDK for implementation in other encoders: http://www.mp3-tech.org/programmer/sources/vbrheadersdk.zip

That one also includes writing "Xing" to the header frame, so I guess many tools of the era would mis-identify VBR encodings with that header as being "Xing".

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #122 –
One more thing - the code compiles smoothly and without errors using MinGW/GCC. Thumbs up.

The ASM code path is only used when compiling with Visual C++/VS - is that correct?
But never mind - the optimization via CFLAGS provides a pretty fast GCC binary as well.  ;D

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #123 –
Yeah, the ASM path should be Visual C++/VS only. And then only for 32 bit compiles.

With modern compilers and instruction sets, the C compiles may not fare any worse. I think John did some speed testing and the 64 bit C-compiles fared very well.

Re: Resurrecting/Preserving the Helix MP3 encoder

Reply #124 –
Quote from: maikmerten on
The problem really is that there is little development interest in MP3 these days.
Sadly, that seems to apply to all lossy audio these days. I guess it's reached "good enough" status, and nobody has any practical ideas on how to improve things beyond the capabilities of AAC/Opus.