Useful TagLib audio attributes.
Submitted by Nir on Thu, 02/12/2015 - 15:07
I've created a spreadsheet of all the audio types supported by TagLib and the more common audio attributes:
https://docs.google.com/spreadsheets/d/1ll69YCtzHIhbgci9DpL7sQKgdJtV7k3D...
Grey cell means the attribute isn't supported for that type. White cell means it's supported, but it's not clear yet whether it's useful or not. Green means useful, red means not. I'll be updating the spreadsheet based on your comments. Keep in mind that I'd only like to index attributes if they're truly useful. Every added attribute means more memory used for your own shares, browsed shares and search results. Once we have a clear picture, I'll modify SoulseekQt accordingly.
Thanks, Nir
Comments
FLAC >>> bits per sample &
FLAC >>> bits per sample\sample rate - NO lenght [perhaps only show if larger and less than 16/44.1 since that being cd quality and thats what you can find most often]. This is very useful for vinyl/tape!!!
Should be in bits/sample format
WAV >>> same as FLAC
[concept idea] There is a possibility to implement an option for lossless results search to do an taglib search and if off, no info will be shown. So when i wanna use i can just toggle it on. Maybe less memory would be used that way.
MP3 >>> just the bitrate and type (i never found lenght that useful, waste of column space, no love)
ex: 320 CBR, 256 ABR, V0 VBR <-- this being the vbr. idk if you can do that but i just hate thouse 217 bitrates, you just dont know what vbr quality it is.
it, xm, mod, s3m ?? Never heard or saw.
I said in the previous thread that this can use a lot of memory. Better use it wisely and cheap.
Hopefully the low-end machine users wont suffer much.
Keep it up Nir.
EDIT: i would also like to add that bitrate for all lossless files is useless WAV 16/44.1 is always 1411kbps (since its uncompressed), should be in red
no length for audio files is
no length for audio files is a sabotage. good that it's already colored green. size is not mentioned in a table so i presume it stays in it's own column - good decision too. other than that:
flac\ape\wave - bits per sample\sample rate, length
mp3\ogg - bitrate, length
so it's simple and fits most users needs.
extending Your idea: the clean info mentioned above is shown as standard with no on\off switch, but - RMB on file - "request more data" - and request is pulled directly from a user showing pop-up table filled with file more technical information. including metadata.
RMB, metadata, pop-up...
RMB, metadata, pop-up... sounds like nicotine+. :)
You can always put stuff in RMB. Why not, ideas are bulletproof. if that goes tru SLSK would need new icons in RMB. a lot of them are repeating eachother. make a contest or something, the one who makes the best RMB icons wins a ______.
Is there anything that makes
Is there anything that makes bits per sample\sample rate more important for FLAC than other file formats like MP3?
VBR is tricky. I modified TagLib to extract VBR quality information, but a lot of non VBR MP3s still have VBR headers, and the quality ranges from 0 to 99. Not sure how that translates to V0-V9.
it informs about the source
it informs about the source of lossless rip. for cd it's 16bit/44.1 Khz. for dvd audio it can be 16 or 24 bit, with sample rate up to 192 Khz - these number define quality available, while bit rate is just generated based on "amount" of material. for silent, less dynamic tracks flacs bit rate may be close to 0, while loud material will have higher bit rate. lossy codecs like mp3s are designed in the different way, so their bit rate defines quality, and mp3 containing silence only still can be in 320kbps
"it informs about the source
"it informs about the source of lossless rip" -- is that true for lossy formats as well?
edit: I understand that the lossy formats don't contain bits per sample information. Would the sample rate info be useful in their case without bits per sample?
Sample rate can be useful for
Previous commenter is correct about sample rate & bit depth providing useful info about the source. As for lossy formats, the input is often filtered to get rid of high frequencies, and it will also be downsampled if the bitrate isn't going to be high enough. So it's less useful to know the sample rate for lossy formats. Also, sub-44.1 kHz lossy files aren't very common nowadays, and rates above 48 aren't even supported by most lossy formats; people will mainly only ever see 44.1 or 48, and IMHO it may just confuse them; they'll start thinking a 48 kHz mp3 must be "better quality" than 44.1, an assumption based on a false premise.
As for "quality" values in the VBR header:
The 0-99 "quality" value in a VBR header is written according to encoder-dependent criteria and has nothing to do with the source input. You can only use the value to compare between things made with the same encoder. IMHO it's useless.
The LAME encoder's "V" number is a command-line parameter that tells LAME's VBR algorithm what target quality to shoot for, quality being measured as a certain amount of quantization noise within a reasonable range. This is an objective measure, whereas perceptual quality is another matter entirely. There's a correlation between this number and the resulting overall bitrate, but it really depends on the audio content; simple/quiet/mono content will have a low bitrate even at high quality settings. So I recommend against inferring a "V" number from the bitrate or from the VBR header's 0-99 "quality" field. Only show LAME encoder settings if there's a LAME tag in the VBR header.
More generally, people who are searching for quality can only really find that out by listening and doing double-blind tests; nothing in a file's metadata will help, especially with all the lossy-to-lossy and lossy-to-lossless transcodes out there.
not really, i don't think so
@Nir
not really, i don't think so
@microwave
indeed; and very informing about VBR
there is also the 32bit
yeah what psynaturecybine wrote. this would aid you so that you can spot easily in which quality the vinyl and tapes are ripped (even tho the file size gave that intel away). cd rips are always 16/44.1, im not sure about SACDs
There is also the 32bit (float), but that is a rare find since its mostly a first step product while ripping vinyls and tapes. you rip to lets say 32/192 (huge file size!!) then convert it to a 24 bit either 24/192 or 24/96. thats the end product. these days there are more and more 24/192 getting made. 10y ago mp3, today lossless, tomorrow maybe DSD, if anyone of you heard about it. http://i.imgur.com/u7kh0gq.png
In some cases there is also the oddish 88.2 sample rate applied.
For lossy files, bitrate and
For lossy files, bitrate and length are important to me. They are the quick way to work out whether I'm finding the right file - at least two recent files I can think of exist in two lengths, and I wanted to find the longer one. Easy with these!
For FLAC/APE/ etc, the length is the only ready useful one. Sample rate less so.
@dogbite makes a good point,
@dogbite makes a good point, that WAV is the one format that doesn't compress, so really only needs a length factor.
Also the factor that we have FLAC, APE and WAV files that are full album rips, with their cue sheets, which makes the length a bit useless!
Okay, so for now I'm going
Okay, so for now I'm going with sample width/rate+length for FLAC and WAV, and bitrate+length for pretty much everything else:
https://www.dropbox.com/s/8ibtfu0nj9admqd/SoulseekQt-2015-2-14.7z?dl=0
I'll update the client as my understanding of the topic improves ;)
with this version I've
with this version I've noticed that in the Uploads tab the status is being refreshed each 10 seconds, is this normal or a bug ?
also that sometimes some uploads reamain in queue, even if the user is disconnected xD
I'm not clear on both points.
I'm not clear on both points. Which part of the uploads tab is only being refreshed only 10 seconds?
Re: uploads of offline users remaining in queue, that's normal unless you have 'Clear Complete/Aborted Uploads' checked, in which case they're supposed to clear roughly five minutes after their last status change.
the status of transfer speed.
the status of transfer speed.
ok, thanks for clarify ;)
running smooth. just few
running smooth. just few minor stuff that should be fixed i think:
should show 44.1 kHz not 44.1hz, and for 96.0 the zero there is obsolete
monkey's audio files still shows bit rate
mp3 showing [quality, time], but lossless showing [time, quality]
edit:
and a little tip (dunno if it's obvious or not) - people won't care or even know to re-share their files in order to have all advantages of taglib. final soulseek with taglib shuld re-scan attributes automatically, or have some kind of pop-up at first run and suggest manually re-sharing.
Excellent feedback, thanks!
Excellent feedback, thanks! The new build on the sidebar should address all of these issues. For re-scanning I've implemented a simple versioning scheme that will automatically rescan all of your files whenever I add new attribute extraction functionality.
ape still shows kbps in front
ape still shows kbps in front of right attributes
WavPack (.wv) is also a
WavPack (.wv) is also a lossless compressed format. I missed that one. but it should have birate BECAUSE...
Hybrid mode
WavPack also incorporates a "hybrid" mode which still provides the features of lossless compression, but it creates two files: a relatively small, high-quality, lossy file (.wv) that can be used by itself; and a "correction" file (.wvc) that, when combined with the lossy file, provides full lossless restoration. This allows the use of lossy and lossless codecs together. -wiki
So it can be lossless and lossy. I think this one should have birate even tho it can be lossless, IDK really you deside.
---------------------------
.MP4 or AAC (Advanced Audio Coding) (yes i hate you) is a crappy lossy format that has like 15 variations and all are sh'eath. May the inventor of it advance to hell.
I dont know what exactly the table is referring to:
AAC (Apple) CBR, ABR, VBR, Constrated VBR
AAC (Nero) CBR, VBR, ABR, ABR-twopass
AAC (winamp FhG) same as bottom
AAC (FDK) -Fraunhofer CBR or VBR with AAC-LC, HE-AAC, HE-AACv2
AAC-LD (Low Depth)
FAAC ???
MP4 (MPEG-4 Part 14) video and audio(AAC)
i think there is even more.. O_o
i hope that helps anyone. >> im out, going to work :|
That's very interesting
That's very interesting information, thanks! Right now WavPack gets the default bitrate+length, I'll add sample rate/width to it as well.
Not sure about AAC, I guess I'll leave it with the default bitrate+length.
now running 2.14 under gbd.
now running 2.14 under gbd. No crashes caught for a while now. Still time of course, but that's what this is all for :)
Hummmmm. 'clear complete
Hummmmm. 'clear complete/aborted uploads' is not working?
Have you used the feature
Have you used the feature before? It takes about five minutes past the upload's last change in state for it to clear. Seems to still be working on my end.
OK. I'll keep an eye on that
OK. I'll keep an eye on that one.
Are we in danger of losing
Are we in danger of losing track of the current testing/debug version?
The new links are kind of vanishing into the stacks of replies!
I'm on 2.14 at the moment
Good point, I put the
Good point, I put the "nightly" builds block back on the sidebar. I'll make sure it always lists the corresponding debug build.
2015-2-17 is crashing on me
2015-2-17 is crashing on me within a few minutes of startup, but the debug version is chugging along. *shrug*
That's very worrisome... it
That's very worrisome... it almost definitely sounds like a problem related to scanning your shared files. What you can try and do, if you're up to it, is divide your shared folders to two locations, share one location (roughly half your share), see if the crash still occurs, if not, try the other location, if so, divide *that* location to two locations and recurse until you have some idea of which files are causing it. If you do decided to try it out, you might want to start with no files shared and see if it still crashes, just to make sure it's related to your shared files.
I've also had numerous
I've also had numerous crashes during the initial scan within minutes. I've tried various builds - the regular and debug releases. It never gets very far before crashing. I've turned off the diagnostics and changed the save client data every x minutes to a higher number. My lossless and mp3 files are on separate drives, so I will try sharing no files and then add them in batches.
Thanks TJT! If you also want
Thanks TJT! If you also want to try running the client in a debugger, these are the instructions:
https://docs.google.com/document/d/1WxE8ZQmTH8UqdM8WaxDfKf6N128ukm_lINMS...
Success with the Windows
Success with the Windows release! I unshared everything and then re-added the folders in small batches with mp3s first and then flac. Maybe there's some conflict in the re-scanning process between builds. Unsharing and re-scanning everything seemed to do the trick.
Interesting... does it also
Interesting... does it also work if you reshare everything in one go?
I spoke too soon. It's still
I spoke too soon. It's still crashing at random spots during the initial scan. I was able to re-add all the folders, but it crashes while scanning the flac files. It makes it a little further each time, as I have it set to save every 2 minutes. There doesn't seem to be any one particular place where it crashes.
Is this just a rescan after
Is this just a rescan after the files already had their audio attributes extracted?
Any chance you can run the client in a debugger?
This is still during the
This is still during the process where the audio attributes are being extracted. The size of the client data file is increasing, but it just randomly crashes. I will try to run it in the debugger on the weekend.
Not sure I'm up for that,
Not sure I'm up for that, with so many files shared and so many people whose download queues would be adversely affected by my sudden unsharing of ½, ¾, ⅞, etc. of my files. Any chance you could cobble together a little standalone app that I can point at a folder to figure out which files (if any) are making TagLib choke?
Why not try it while you aren
Why not try it while you aren't connected to the internet or use another username temporarily? It wouldn't adversely affect anybody that way.
Disconnect from the Internet?
Disconnect from the Internet?! Horrors! :) OK, I'll try that.
Update: No crashes, sorry. I followed these steps: disable network connection, start SoulseekQt (2015-2-17) in the debugger, remove shares, quit and restart Soulseek (just in case something was cached), start again, add folder, watch Diagnostics > Logs > File Scanning and wait for it to finish, wait 2 more minutes for data to save. Keep adding folders, watching logs, waiting for save until done.
There were no crashes, but I do see this a few times in my gdb log:
BFD: C:\Windows\SysWOW64\WMVCORE.DLL: Warning: Ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .relocAlso, as I added folders, the Diagnostics > Logs > Shared File Not Found pane filled up with a list of all my files, and the paths were all lowercase. Nothing to worry about, right?
Hang on in there with the
Hang on in there with the debug build. I went through the same strangeness, but did get a crash after a couple of days.
Try this release build if you
Try this release build if you can: https://www.dropbox.com/s/g75y03m50x0680f/SoulseekQt-2015-2-20.7z?dl=0
It simplifies the way file scan requests are queued on a secondary thread, and catches any exceptions TagLib might be throwing. Total shot in the dark, but who knows.
Still crashing I'm afraid.
Still crashing I'm afraid. Even more than it had before. Maybe it just can't handle that many thousands of files. When I remove the files where it's crashing, it picks up and continues but there's something tripping it up as far as flac files.
Have you tried the latest
Have you tried the latest debug build on this?
I found it was getting stuck on specific FLAC files, but for unaccountable reasons, this stopped happening.
How many thousand files are you talking about?
I haven't tried the debug
I haven't tried the debug version, as I see only the 2-22 build for Windows on the sidebar. Maybe it's a certain encoder version of flac files it can't handle? This is with well over 100,000 files. There's no rhyme or reason where it's crashing. I thought it was because of image flac files, but it also crashes on the single files.
Might there be a specific
Might there be a specific file or folder that crashes the client when shared on their own? Maybe I can use it to reproduce the problem on my end. Give me a few, I'll post a debug version of the 22 build for when you get the time.
2/22 debug build: https://www
2/22 debug build: https://www.dropbox.com/s/qz0jaw5c8t9hvih/SoulseekQt-2015-2-22-debug.7z?...
I'd really be curious to know
I'd really be curious to know if you would get a crash running in debug mode if you get the time. I'd really like to keep TagLib in there, but if I can't stabilize it (and assuming that it's really TagLib that's causing these crashes) I'd have to take it out of the client...
It was able to scan through
It was able to scan through all files without crashing in debug mode. It's been running pretty smoothly for the last few hours, but it seems to freeze a little more often when it's backing up the client data. Thanks for your efforts.
Thanks for testing TJT!
Thanks for testing TJT! Unfortunately I can't release this version of the client until I can get the release build to stop crashing... another shot in the dark: Do you have the diagnostics tab open? I know you need it to see who's getting a files not shared message, but I wonder if having it off and re-sharing all your files with the release build will still result in a crash.
The 2-22 build isn't crashing
The 2-22 build isn't crashing on me. It made it all the way through the scanning process (with the diagnostics tab turned on) and hasn't crashed since, so whatever you did with the latest build appears to be working. TagLib lives to see another day.
Huh, the only thing that
Huh, the only thing that changed between the 2/20 and 2/22 builds is a minor fix related to the reported number of files removed when rescanning your shares. Shouldn't account for the crashes stopping. I did create a 1.3TB share by making lots of copies of the FLAC you sent me and a bunch of other audio files and tried to get the client to crash by scanning it, even went as far as hacking it to scan the same share ten times in a row (~500k files) and nothing. I'm reserving judgement for now... still not sure what's going on.
Thanks, Nir
Pages