Incomplete anlysis, waveform overview and display, of a song file, after conducting library "Analyze" #11280
Comments
|
Decoding stops at the first unrecoverable error. Please check the logs for more information. |
What's the fastest way to check the logs? I'm look through the .mixxx folder, and I have about 10 log files to look at. EDIT: How do I check logs? |
|
Start Mixxx, reset the waveform data of the affected song, then load it on a deck. The log of the current session is in mixxx.log. |
|
Starting Please also send me one of the affected files. It would be interesting to investigate what's wrong and which decoder (libmad or ffmpeg) fails to decode it. |
|
@nPrevail Yes, could also run Mixxx from the command line with |
|
The |
I have tried resetting the waveform. I actually reset all the parameters, and had loaded onto the deck, and the issue would still persist. It's unfortunate that none of these logs are timestamped, but I'll paste all the relevant log lines I have. |
|
Resetting the waveform enforces the analyzer to re-decode the whole file for getting the logs. The error will not be fixed magically. |
|
Bugs that fix themselves under unknown circumstances would be the worst case. Reproducible bugs are good bugs ;) |
|
Logs Debug [AnalyzerThread 0 #1]: AnalyzerThread - Analyzing QFileInfo(/home/nPrev/Music/DJ (LL)/Disco/disco edits and covers/Revivra Alias Estéphe & Vulzor - Set It Out - Mercy - 02 Mercy.flac) |
|
The FLAC decoder is trustworthy, the last bug has been fixed long ago. Unfortunately, some of your files seem to be corrupt. If you start |
|
The main culprit file is: /home/nPrev/Music/DJ (LL)/Disco/disco edits and covers/Revivra Alias Estéphe & Vulzor - Set It Out - Mercy - 02 Mercy.flac" |
Ah I see... I wonder how that happened... |
|
Use the official FLAC tools to analyze the file contents. Should be possible somehow. If they report that the file is ok then we need to check our FLAC decoder. |
|
And don't delete or modify the file! Keep it until the case could be closed. |
|
I have the "tainted" file on another drive. I can probably tinker with FLAC tools to analyze the contents for corruption. |
|
Can anyone point out which FLAC tools I can use? I've installed mingw64-flac-tools and mingw64-flac, but I don't know how to use it...
|
|
So, I ran I guess we can confirm that I just happen to have a corrupted file? I have no idea how it happened though... |
|
Now you need to find out what caused this corruption. Mixxx could only be involved if TagLib corrupts FLAC files when writing metadata. |
Got it. Well, some good news (for now). I ran this bash script I found on github, found all the corrupted tracks, fixed all the corrupted tracks (by running the script that pretty much self-reencoded flac to flac), and it seemed to fix all the corruption! I used this script: https://github.com/cgomesu/bash-flac-diag Worked perfectly! I'm glad to know it can be resolved in case it happens again. So this time around, a clean slate will help me figure out what's causing the issue. |
|
Great news. Which type of issue did the script report? The script uses What would be that appropriate behavior of Mixxx that we can avoid future bug reports like this? |
|
When may investigate which tests the FLAC tool does and compare it with the Mixxx implemtation. |
I'll talk about what I did and the behavior I saw from the script. The script came with four separate bash scripts: flac diagnosis for good or bad songs, flac fix, flac remove, and install (installs all related tools necessary for FLAC). I used everything except "install.sh" and "bad_flac_remover.sh" The "flac_diag.sh" script indicated if the song file was bad or good. Within the script's directory, the script creates a folder called "log," and then the script creates two logs: one for bad, the other for good. The script also creates a directory called "errors,"and that directory created individual error logs for each bad song file. I then ran "bad_flac_fixer.sh" to fix all the corrupted tracks mentioned from the log directory. It pretty much "self re-encoded the corrupt files as if they were new again (encoding from FLAC to FLAC, and same file source). The best part is that I didn't need to locate any directories as the script found and logged the directories of the corrupt files. Overall, for scanning and diagnosing 4,000+ tracks, the process took about 60 minutes to analyze. I had about 70 bad FLAC files. Fixing the flac files probably took about 10 minutes. Obviously this will vary based on computer specs. More details on how and what the script does can be found in the readme, and it's pretty straight forward. Here are some screen shots:
It'd be neat if we could implement this type of script into Mixxx. Like a "Diagnose" and "Fix" button from the "Analyze" section in Mixxx. Unfortunately, it seems to only currently work with FLAC files, and depending on a person's filesystem and configuration, there may be some prerequisites needed to ensure the FLAC tools work (however, the script's readme states that most modern distros should already have these FLAC tools installed by default). |
|
Okay, I thought this issue was over, but I discovered a few more things that also conflict in Mixxx: ID3v2 tags This error causes the same error I mentioned: incomplete waveform analysis for songs with this type of error. As I remove the ID3v2 tags from these songs, what type of tag is recommended to be used in Mixxx? From the same FLAC fixing script, I received the following outputs. I bolded the errors that are causing issues, and I have to fix these issues in some other method because this script can't remove ID3v2 tags: .............. flac 1.3.4 ERROR: input file /home/nPrev/Music/DJ (LL)/Disco/in the zone/09 Always There.flac has an ID3v2 tag .............. flac 1.3.4 ERROR: input file /home/nPrev/Music/DJ (LL)/Electronic dance music/Deep house/out there/03 Glow & Glare.flac has an ID3v2 tag flac 1.3.4 ERROR: input file /home/nPrev/Music/DJ (LL)/Electronic dance music/Techno/getting started/04 The Sugarcubes - Motorcrash [Justin Robertson Mix].flac has an ID3v2 tag flac 1.3.4 ERROR: input file /home/nPrev/Music/DJ (LL)/Parties/Ballroom/Disco Swing/01. Unknown - Title 1.flac has an ID3v2 tag |
|
This should not be a Mixxx issue. ID3v2 tags in FLAC files are supported as a fallback by most software but not recommended. https://xiph.org/flac/faq.html#general__tagging Please consult the official docs when in doubt. |
|
I ran Mixxx via terminal so I could see a live log. I reset the Mixxx file data (BPM, waveform, key, and etc.) with the ID3v2 issue, and I received this output: I know we've seen this error before, but I guess this script is unable to fix/re-encode the FLAC file because of the ID3v2 tag: I'll read the general tagging link you sent. |
|
The other strange thing too is that this song file 09 Always There.flac came from a compilation of other songs downloaded from Bandcamp, yet this song seems to be the only one affected in the bunch... This song file plays fine in VLC, but it prevents Mixxx from fully scanning the waveform. |
|
If the FLAC decoder fails to parse the byte stream from your files with non-standard tags this is still not a Mixxx issue. We can't do anything about it. |
|
From what I learned, it's difficult to remove ID3v2 tags, and I did find a script to fix MP3 files (and maybe FLAC), but fortunately, I have backup copies of these songs, and these backups seem to work fine. Just wanted to share the possible solution in case folks accidentally have ID3v2 data in their FLAC files. |
|
Is the waveform truncated or does it not line up with the actual track (so, it ends up being stretched). I've been seeing a similar issue on the main branch where track waveforms are sometimes compressed like this: (this is deck A doubled to deck B):
Usually when it happens when loading a new file, it only happens the first time the file is loading. Reloading it in the same deck afterwards fixes the waveform. There's nothing in the log at the standard verbosity level, so I'll need to check if anything useful shows up in a trace log. |
|
It's usually truncated, and also the track stops playing when it reaches the abrupt end (not playing the complete track from beginning to end, but stopping at the gap, like your Deck B's waveform). After fixing it, the waveform still shows up truncated, but like you said, once I reset and re-analyze the song file, the waveform is analyzed correctly and is no longer truncated. HOWEVER, that only happens after I fix my track corruption, which I had a handful of corrupted FLAC files. |
This is not the case here when you look at the pictures. The waveform is just wrongly scaled, but otherwise complete on both decks. It's the same track, too. |
Ah you're right! My apologies for not seeing that the first time. From my original picture of my post, the song and waveform would instantly cut off and would stop playing. After fixing the corrupt track, it would play. After resetting and analyze the waveform, the waveform would analyze fine. |
I analyzed my library of files, and in some instances, some of my files would be analyzed but incompletely scanned. This image attached to this message is what I see.
When playing the incomplete song file, the audio cuts off before the song reaches the end and the deck stops playing.
I have tried "hiding" the song file, deleting the song file data from the library, and I have tried reanalyzing the song file, yet it rescans and still shows as incomplete at the same time stamp.
There is nothing wrong with the song file itself; it plays fine in a music player (ie. VLC)
I happen to have backups of my music files; back ups of the same songs in other hard drives. The only solution I found was to use the back up of the song file from the directory folder, and overwrite the original song from my Mixxx music folder.
I have tried duplicating the song file in Mixxx library/folder (copy and pasting the song file), and it does not fix the issue. But grabbing the song file, which had a different "created by" date, and a slightly different file size (unedited metadata?) seemed to fix the issue.
Perhaps this is a metadata song file issue?
The text was updated successfully, but these errors were encountered: