-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
feat: store tracklist as tag comment on recording #13761
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
feat: store tracklist as tag comment on recording #13761
Conversation
5108a46 to
acc29fb
Compare
|
considering the complications and tradeoffs there are with writing large metadata, why not write this tracklist as a separate file like the cuesheet? Is there that much value to having it part of the file metadata? |
Because that's not the feature 😃 We already support the ability to generate a cue file, but there was a requested feature to have the ability to store the track. I think that's a fair request as the cue file isn't embedded. |
|
fully agree, I just find it weird that its a different format from the cuesheet, so I figured these were two different features. |
|
Didn't check the code, but I was wondering: Is this only for MP3/ID3? For FLAC I think there is the |
Yes - only for MP3/ID3 and Wave so far. Since the FLAC encoder inherits the Wave one, it would also support the
Nice, I'm wondering how widely is this supported? It feels like some custom logic that could be added in the |
bfe592c to
d072fbc
Compare
|
(Edit: didn't work :( ) |
d072fbc to
0a8ab06
Compare
0a8ab06 to
d072fbc
Compare
0bfc6b4 to
eba3cfd
Compare
daschuer
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can confirm it works for mp3, but unfortunately not for wav.
158cdaa to
9f54851
Compare
|
https://mutagen-specs.readthedocs.io/en/latest/id3/id3v2.2.html#comments |
|
Ah that makes sense! Now that you pointed this out, I just thought I could use TagLib instead of liblame. I have reworked it and it works great across the board (ffprobe, vlc, mixxx tested) The only rough edge is the ellipsis/UTF8 truncating, but I believe this is edge case enough the ignore for now. In case we get complains, we can always focus on solving the root cause problem, which is a limitation in the encoder callback API, not allowing to prepend data. |
daschuer
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh just noticed I had a pending review.
Yep, that sounds like a wise approach. |
|
The first recording after enable tracklist does not work.
|
|
I have pushed a rewrite of the wave encoder with TagLib. Sadly, the whole I believe I also fixed the bug you had found. |
daschuer
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can no longer make the feature work for wav.
|
Could you share some more details @daschuer? Just tested locally with WAV and everything seems to work fine on my end. |
95315d7 to
2bd40a3
Compare
|
pre-commit is complaining. |
daschuer
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for coming back to this. It works like a charm for mp3 and wav. Left w view final comments.
src/encoder/encoderffmpegcore.cpp
Outdated
| // Currently this method is used before init() once to save artist, title and album | ||
| // | ||
| void EncoderFfmpegCore::updateMetaData(const QString& artist, const QString& title, const QString& album) { | ||
| void EncoderFfmpegCore::updateMetaData(const QString& artist, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This function does now only print a debug message. Is this desired? Is the comment outdated?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For some reasons, the previously set values (m_strMetaData*) was never read so this appears to have no action. I have set it to a no-op now.
ea5423f to
3b5e234
Compare





Closes #9134
Implemented for MP3 and Wave and tested with both.
ffprobeexample with MP3Note on MP3
After a long day of learning MP3 spec, it would appears that our implementation was somewhat flawed. My understanding is that the
Xingframe that contains various parameter about the MP3 frames is expect in the beginning of the file, however we currently overwrite the first frames with it, leading to data loss. Since a frame is < 100ms, this is not something you can easily hear.Second point is, we currently only write IDv1 (automatically supported by lame) but this limits the comment to 30 bytes. In order to lift this limit (and reach the hard limit of 2**32), we need to write ID3v2, but those are expected as header (unlike ID3v1 which can be appended in the footer when flushing the file.
In an ideal world, we would want to shift the file content to fit the ID3 header + the Xing frame. Because this basically requires to tear down the whole
EncoderCallbackmecanism, this instead adds a static header of 10K, which will be filled with the header, leading to a hard limit for comment (limit which depends of the artist, title and album size, as well the Xing frame size.Appreciate this is far from optimal, but hopefully we can find an acceptable trade-off