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: v2.0 beta 12 says FLAC files encoded in 2007 are corrupt (Read 6576 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: v2.0 beta 12 says FLAC files encoded in 2007 are corrupt

Reply #25 –
Dang, was I wrong the second time about -F?
Apologies. Big facepalm moment yes.

-f and -F in brief:
Small "f" forces overwrite, so you need to do that on re-encode.
Big "F" decodes through errors. Even if there is an error, it will take the audio it got.
"Together they are dangerous" in that the new file will look OK even if the old audio was corrupted. So only use -F when you have to.
(Looks like you have to here. I was wrong. Apologies again.)


But you are using foobar2000, so - because you have ran a re-encode - here is what you can do if there are only a few troublemakers ("a few" meaning, so few it pays off to single out only them and you have space enough on the drive):
(1) You can search up the ones that were not re-encoded. If you used 1.4 to reencode, the query
%__tool% HAS flac AND NOT %__tool% HAS 1.4.
will select those which remain. Those are precisely the ones that need re-encoding, and now you can see how many GB they are!
(2) Dump these into a playlist. Save that playlist.
(3) Copy them to a new folder (say, "f:\reencode" - this requires you to have enough space on the drive) using a pattern like e.g.
%directoryname%\%filename%
This presumes that you have them all at the same "directory depth", and it requires you to have enough space on the drive.
(The problem about using "%path%" as naming is that all files will be .flac.flac - I actually often use that still, and rename afterwards.)
(4) cd to f:\reencode and run the same command. Now it will traverse only that directory.
(5) You can use foo_bitcompare to make sure the audio is the same in the playlist in (2).







Re: v2.0 beta 12 says FLAC files encoded in 2007 are corrupt

Reply #26 –
No worries! All I lost is a little bit of time, which was mainly spent having a good conversation with my wife, so nothing was lost!

Back to the topic at hand, I would estimate there are over 1000 files that were not re-encoded. I'm more inclined to just run the whole thing again with the big -F, since I have multiple backups anyway and plenty of spare time tonight.

Running it again with this command line.
Code: [Select]
f:
FOR /r %%f IN (*.flac) DO flac -F -5 -fV "%%f"
pause

We'll see what happens!
Think millionaire, but with cannons.

Re: v2.0 beta 12 says FLAC files encoded in 2007 are corrupt

Reply #27 –
Even with -F it refuses the files.
I just tried this on a single dir and this is the error I get:
Code: [Select]
ERROR: input file F:\music\Anime\Nadesico\Martian Successor Nadesico TV OST\10 - I Want To Be Your Number One.flac has an ID3v2 tag

**EDIT**
It occurs to me that the -F was before the input file in the command line in a previous example, but I don't know how to do that in a FOR loop. Is that my problem? How would I write this? My apologies, I don't know the proper syntax for this.
Think millionaire, but with cannons.

Re: v2.0 beta 12 says FLAC files encoded in 2007 are corrupt

Reply #28 –
Quote from: Cannonaire on
It occurs to me that the -F was before the input file in the command line in a previous example, but I don't know how to do that in a FOR loop. Is that my problem? How would I write this?
I don't follow what you mean.
Code: [Select]
FOR /r %%f IN (*.flac) DO flac -F -5 -fV "%%f"
...looks OK to me, the "-F" comes after "flac" and before "%%f" (which is the token representing the input file), so what do you think the problem is?
Quote from: Cannonaire on
My apologies, I don't know the proper syntax for this.
  • FOR <parameters> IN (<search>) DO <operation> initiates the looping structure, performing the <operation> on all items which match <search>;
  • /r causes the search to recurse subdirectories;
  • %% is the prefix to a token declaration (within batch files, use only single % on the command line), so in this specific case %%f is declared to represent each item which matches the search – the choice of letter must not conflict with other tokens in use;
  • (*.flac) searches for all files with the .flac extension;
  • flac <parameters> is the operation to be performed on each item found;
  • "%%f%" is the token representing the search item (as previously declared), but is in quotes or double-quotes (it doesn't matter which, but if the %%f string might contain one use the other) to prevent any spaces in the %%f string causing a misinterpretation (because an unquoted space is the end-of-token marker).
It's your privilege to disagree, but that doesn't make you right and me wrong.

Re: v2.0 beta 12 says FLAC files encoded in 2007 are corrupt

Reply #29 –
Found it!? Maybe. If I did, then good news.

Solution first: Mp3tag - no re-encoding needed. (Edit: found a discussion here as well: https://community.mp3tag.de/t/flac-version-1-4-x-and-tags/59228/1 )

(1) Dump the offending files into Mp3tag (you can do that by querying up in fb2k, mark all and drag them over).
With the "Tag" column activated, you will see FLAC (FLAC ID3etc, like this:

(2) The following will cut away tags from them all, and then "undo" but in the right way. Cross fingres that you don't get a power outage (well you have backup) while it is doing the work:
* Mark all,
* Ctrl-x
* Ctrl-z
(3) Now the "Tag" column should show "FLAC (FLAC)". And flac -t will report them all just fine.


The obligatory follow-up questions appear to have the following answers:

* Why does Mp3tag work after an "undo"?
Mp3tag does not "undo" by writing back the old files, only by writing back the old tags - and in the appropriate format.

* Why did the -f, -F, -fF not work?
Those should work if there is only ID3v1 at the end. But here the file starts with ID3.
And we should have noticed from your error messages.

Re: v2.0 beta 12 says FLAC files encoded in 2007 are corrupt

Reply #30 –
Thank you Porcus, and everyone else! MP3Tag did the trick! Turns out there were 1480 tracks with bad tags. Definitely not something I would have been able to do manually.
Porcus, if you still want a sample I can send one to you, but I think the screenshot will probably do.
Here's the MP3Tag screenshot:
Think millionaire, but with cannons.

Re: v2.0 beta 12 says FLAC files encoded in 2007 are corrupt

Reply #31 –
Nah, I just needed to realize that EAC also writes ID3v2 tags at the beginning ... I don't need more files now :-)


It also seems to me that fb2kv2 beta 16 removes the leading ID3v2 tags if you ask it to rewrite/update tags.
But it leaves the trailing ID3v1 in, for reasons that Peter outlined in Reply #6.

For the hell of it, I tried to paste an APEv2 tag after the audio as well. Nothing seems to recognize that, but Mp3tag can remove that as well. Here you can see "how it looks" although your browser will probably not show you all the control characters, for that you need more of a text editing application: https://pastebin.com/raw/pssfKdbn
Contents, in order:
* The ID3v2 tag of one track (Bruce Soord, this is copied from what EAC wrote to a rip due to ticking the ID3 check box)
** "fLaC" is supposed to be the beginning of an actual FLAC file. After "reference libFLAC 1.3.2 20221022" (the vendor string, what I used to encode the signal),
** there follows a COMMENT which is the only proper FLAC tag in the file.
** Then some gibberish that is the actual audio (only 44 samples)
* later on the line, APETAGEX starts the APEv2 tag (not the same album as the ID3v2 tag I pasted in earlier - this is from the track you can 'hear' a millisecond of!). The APEv2 tag ends in a second APETAGEX and a few control characters
* Starting with TAG: An ID3v1 tag which again is copied from the EAC ripped FLAC file.

For a compliant FLAC file, only the "**" are supposed to be there!

Re: v2.0 beta 12 says FLAC files encoded in 2007 are corrupt

Reply #32 –
Quote from: Peter on
I was thinking about removal with 'rewrite file tags', but it's not THAT easy to be 100% sure that 'TAG' at EOF-128 is an ID3 tag not some part of the file. We've had that happen with some other format already.

Would have to figure out where the legitimate EOF of FLAC stream is and look for ID3 tag from there. Maybe for some future fb2k update, not right now.

"not right now" is noted, but 1.6.14 and 2.0 beta 17 (x64) also differ in what they read and how.
In the previous reply #29 I let EAC tag a rip to FLAC. With that checkbox thing ticked, it writes a file with ID3v2 first, then stars the fLaC with Vorbis comments, then the audio and then the TAG starts the ID3v1 chunk. This far, not all well but all "as known".

* Dump it into two fb2k instances, one 1.6.14 and one beta 17, x64
Both look identical, also in Properties.
* In 1.6.14, Remove tags from file(s). In both, Reload info from file(s).
What actually happens: Vorbis comments removed, both ID3 tagsets remain.
1.6.14 shows: tag types id3v2.3|id3v1 and under properties, displays the ID3v2.3 tagset
2.0 beta 17 shows: no tag type, and consistently empty under properties.
* In 1.6.14 on this now-altered file, Rewrite file tags.
What actually happens: ID3 tags are still there, but the ID3v2 tags are copied into Vorbis comments.
Both now show it as if it had no ID3v2.3, but it still has.
* In 2.0 beta 17 on this now-altered-again file, Remove tags from file(s).
What happens: It successfully nukes both ID3v2.3 and Vorbis comments. It leaves in ID3v1.
1.6.14 shows: the ID3v1 tags.
2.0 beta 17 shows: nothing, ignoring the ID3.


Trying a bit back and forth it seems that both versions can remove some ID3v2.3 tagsets but not all, and not the same ones.
 

Re: v2.0 beta 12 says FLAC files encoded in 2007 are corrupt

Reply #33 –
Recently, I downloaded a file from the Internet, which, when passed through the file integrity verifier in foobar 1.6.14, throws a garbage at the end of file error. Unfortunately, after deleting the tags, it's still the same.
MP3tag doesn't help either.
FLAC 1.3.3 decodes this file without errors. I don't know what's wrong with this file, I guess something other than id3 tags since neither mp3tag nor foobar remove this information and file integrity verifier reports the same error.
Below is a link to the file
https://bit.ly/2lM1tPC

Re: v2.0 beta 12 says FLAC files encoded in 2007 are corrupt

Reply #35 –
A quick check reveals that it is encoded with 1.3.1 at -6. Re-encoding with that executable (for Windows x64) and that setting, I get precisely the same file except that the final few bytes are cut off.
Edit:
Using a hex editor, those bytes appear to be
F0 00 FF 0F 44 44 40 48 46 3C 36 0E 55 FF F0

Re: v2.0 beta 12 says FLAC files encoded in 2007 are corrupt

Reply #36 –
OK, i converted this and bit compare says, that all tracks decoded the same, no differences found. I was just curious what makes this file suspicious by flac higher than 1.4.

Re: v2.0 beta 12 says FLAC files encoded in 2007 are corrupt

Reply #37 –
What makes flac 1.4.0 raise the flag is that it implemented a become more zealously checking after what-should-be EOF, than 1.3.x.
What those bytes actually are ... does anyone recognize it?