With mp3s, the length, bitrate, sampling and size column data won't be shown until you either load the song to a deck or build overviews/analyze the files.

Thanks for the reply - but it isn't an answer.

Why?

1. Size (File Size) I don't understand.

2. Also for the others I don't see any performance issues / differences to .wav files because the info is at the beginning of the file. In a .wav file it's typically at the end (a new seek in the file).

How isn't that an answer? The program has to read the file first before that info can be filled in. Why? That I can't answer, only the developers can. But this is how it's always been for mp3 files in SSL.

This has been constant from version to version. Some of the tags read right away, some need to be loaded to a deck, some need the overviews built and some even then won't show it.


The version of ID3 tag is important, as well as the volume of content on it. It is common for songs downloaded from "various" websites have ID3 tags that are so jammed, you can't write or save even a bpm value to it. The solution is to strip the tag which creates the room needed to store and display the proper info.

Hi Chad,

sorry - but your reply isn't also an answer:

Why is there a difference between MP3 and WAV files when I move them from the files menu to the crates:

Your reply "Some of the tags read right away, some need to be loaded to a deck, some need the overviews built and some even then won't show it."

1.
I don't understand as developer: The ID3 tag (frames) are in one stream to read. you have it whenever you read it - it doesn't matter if you load it to a deck, overview it, move it to the crate, etc.

A cleanup of the tags must/should be done always (you can do it with the 1 time loading subroutine!). However - when I get a file - I remove all ID3 frames and start from the beginning to avoid the shit.

2. file size:
MP3 or WAV - you always have the file size! Why are you asking it for the WAV but not for the MP3 file when moving it to the crate.

When you say "This has been constant from version to version" .. I think you mean it's "constant different from MP3 to WAV" ;-)

3. length, bit reate

As I said multiple times now:

ID3 tag is at the beginning of a MP3 file. So you have it with the first READ after the OPEN.

For WAV files you have to OPEN it and SEEK multiple times until you have it (because it's at the end of the file) (of course you can SEEK one time back and search for a sub-chunk "id3 " and start from there but also slower ..)

So why are you doing the "overhead" for WAV files when moving them from the files to the crates - and why are you doing "no overhead" for MP3 files?

A developer should make a reply please to explain that. ;-)