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
0bfc6b4 to
eba3cfd
Compare
daschuer
left a comment
There was a problem hiding this comment.
I can confirm it works for mp3, but unfortunately not for wav.
4a1999d to
ff291d2
Compare
|
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.
Thank you for coming back to this. It works like a charm for mp3 and wav. Left w view final comments.
| // 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.
This function does now only print a debug message. Is this desired? Is the comment outdated?
There was a problem hiding this comment.
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.
|
|
||
| <item row="6" column="0" colspan="3"> | ||
| <widget class="QWidget" name="compressionGroup"> | ||
| <layout class="QHBoxLayout" name="compressionHLayout"> |
There was a problem hiding this comment.
The in indentation is broken. The UI editor has sometime its own ideas. It is probably best to revert all unrelated edits manually. Please keep also the extra new lines @ronso0 has introduced.
There was a problem hiding this comment.
It is better to let the reviewer resolve the issue. I need to check anyway. In this case it is not resolved.
There was a problem hiding this comment.
In this case it is not resolved
This was an accident.
It is better to let the reviewer resolve the issue
I'd be happy to find the few cases where you have said to new contributors that you didn't mind whether it was the reviewer or the author resolving the comment.
Some consistency on your ways of working would be appreciated to reduce as much as possible friction.
3b5e234 to
782f1ee
Compare
|
I took the initiative to already auto-squash the commits as all the feedback has been addressed now, so hopefully it can get a quick merge |
|
Such early rebase, requires me to read the whole PR again. So it is not a receipt for a quick merge actually. |
|
|
||
| <item row="6" column="0" colspan="3"> | ||
| <widget class="QWidget" name="compressionGroup"> | ||
| <layout class="QHBoxLayout" name="compressionHLayout"> |
There was a problem hiding this comment.
It is better to let the reviewer resolve the issue. I need to check anyway. In this case it is not resolved.
|
I can confirm it sitil works. |
Aligned to my comment above, I made sure to squash my commit ensure a null diff so there was no risk of a regressing (and need for retesting) |
daschuer
left a comment
There was a problem hiding this comment.
Oh, unfortunately conflicts have developed.
I have also found some left over issues.
| void EncoderWave::flush() { | ||
| sf_write_sync(m_pSndfile); | ||
|
|
||
| auto trackList = getTrackList().join("\n"); |
There was a problem hiding this comment.
I noticed you have only fixed the unknown auto issues for mp3
| auto trackList = getTrackList().join("\n"); | |
| QString trackList = getTrackList().join("\n"); |
There was a problem hiding this comment.
do we also have length constrains here?
| tag.setAlbum(QStringToTString(m_metaDataAlbum)); | ||
| tag.setComment(QStringToTString(trackList)); | ||
|
|
||
| auto tagBuffer = tag.render(); |
There was a problem hiding this comment.
| auto tagBuffer = tag.render(); | |
| TagLib::ByteVector tagBuffer = tag.render(); |
| tagBuffer.size()); | ||
|
|
||
| // Update the file header with the new file size | ||
| auto fileSize = m_pCallback->tell(); |
There was a problem hiding this comment.
| auto fileSize = m_pCallback->tell(); | |
| int fileSize = m_pCallback->tell(); |
|
|
||
| EncoderVorbis::~EncoderVorbis() { | ||
| if (m_bStreamInitialized) { | ||
| auto trackList = m_trackList.join("\n"); |
There was a problem hiding this comment.
Another instance ...
| auto trackList = m_trackList.join("\n"); | |
| QString trackList = m_trackList.join("\n"); |
daschuer
left a comment
There was a problem hiding this comment.
LGTM. Thank you. You can rebase this branch and we can merge.
f7c80f2 to
334663f
Compare
334663f to
548094e
Compare
|
Hi @daschuer, this should now be ready to merge |
|
For some reason this makes my Flac reocrdings unusable, see errors below.
Admittedly, this is on outdated Ubuntu 20.04.5 with Qt 6.2.3. ffprobe rec-broken.flacWhen I try to load such a Flac recording in Mixxx, I get these errors: These are the decoders in use: Opening In Audacity also fails. |
|
Did you try to uncheck |
|
Oh, I didn't even spot that.. |

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