Skip to main content

Topic: foo_dumb (Read 213484 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • kode54
  • [*][*][*][*][*]
  • Administrator
foo_dumb
Reply #300
Nothing, except that you may or may not want to use N loops and a timed fade for some files.

  • Ligushka
  • [*]
foo_dumb
Reply #301
METROiD - The Punisher +4trn.mod doesn't sound right with the synth in right channel starting at 0:08, and the "blips" in left channel don't sound right either. Compare to previous versions of DUMB or play in VLC to hear the difference.

I'm running foobar 1.1.9 and DUMB 0.9.9.45. Here are my settings:


  • kode54
  • [*][*][*][*][*]
  • Administrator
foo_dumb
Reply #302
Cool, another module which uses the Protracker Invert Loop effect. (EFx) The only known players which support this effect are Protracker (on the Amiga), my fork of DUMB, XMPlay with MOD set to PT1 mode, 8bit Bubsy's Protracker SDL, and the EaglePlayer driver used by UADE for MOD playback. Anything else is not guaranteed to sound correct.

  • Ligushka
  • [*]
foo_dumb
Reply #303
Very well, thank you for the prompt explanation.

  • 8bitbubsy
  • [*]
foo_dumb
Reply #304
Cool, another module which uses the Protracker Invert Loop effect. (EFx)

There are plenty of ProTracker .MODs using this effect, take a closer look around. emax, wotw, groo, tdk and even maktone (at least in one ore more of his MODs)!
Also foo_dumb.dll does this effect wrong, use my ProTracker rewrite for a reference (and tunes like emax-doz.mod, orgasmic-chipper.mod, einstein.mod)

  • kode54
  • [*][*][*][*][*]
  • Administrator
foo_dumb
Reply #305
But wait, I did use your rewrite for reference. Needs more work, I guess.
  • Last Edit: 24 February, 2012, 01:12:23 PM by kode54

  • deus-ex
  • [*][*][*][*]
foo_dumb
Reply #306
I noticed an issue with the module beep.it by Wayfinder. Foo_DUMB stutters during playback from Order 31 to 33, obviously due to some calculations? Though my overall CPU usage during playback of this particular orders peeks at 13% (Intel i7 Quadcore + 4 virtual cores), raw CPU power does not appear to be the bottleneck. Disabling all DSPs in the Foobar2000 playback chain I still witness a very noticeable slowdown during playback of these orders.
Best regards
deus-ex

  • kode54
  • [*][*][*][*][*]
  • Administrator
foo_dumb
Reply #307
How do you have foo_dumb configured? That range plays back in real-time here, although it does sound a bit odd. And yes, 13%, or more specifically, 12.5%, would be 100% of one core of your processor.

With my settings, which are the defaults except for looping forever and linear volume ramping, result in using about 7% of my dual core processor, which is 14% of one core.

  • deus-ex
  • [*][*][*][*]
foo_dumb
Reply #308
Found it! Since you reported the module to be playing fine on a Dual core system I got curious and started off with a fresh installation of foobar2000 and foo_dumb being the only plugin installed! Then after adding back on setting after the other step by step I could narrow it down to foo_dumbs interpolation setting. Usually I have this set to "none" in order to have it not alter the sound. Setting it to "linear" or "cubic" eliminates the slow downs for me completely, no matter how many DSPs and Visual effect plugins I have active at the same time.

Are you able to reproduce the stuttering when setting foo_dumbs interpolation to "none" as well?
  • Last Edit: 28 February, 2012, 03:08:56 PM by deus-ex
Best regards
deus-ex

  • kode54
  • [*][*][*][*][*]
  • Administrator
foo_dumb
Reply #309
I certainly am. The thing is, it's using a band-limited synthesizer for that mode, and it's not being utilized in the most optimal matter. There isn't much I can do, short of re-adding the original aliased mixing mode. While the original "none" mode was a lot faster, it also had aliasing and distortion of higher pitched samples, for instance.

  • deus-ex
  • [*][*][*][*]
foo_dumb
Reply #310
Well, I wasn't too uncomfortable with this previous method anyway so I would welcome it back as another interpolation option to choose from. To distinct from the other methods it could go by something utilizing one of these words: old, fast, easy, light, non-limited. Or maybe rename the current "none" interpolation mode using something like: enhanced, advanced, improved, strong, band-limited?
Best regards
deus-ex

  • VEG
  • [*][*]
foo_dumb
Reply #311
Please add support for *.mo3 in *.mdz (zipped module).
Sorry for my English.

  • kode54
  • [*][*][*][*][*]
  • Administrator
foo_dumb
Reply #312
Is that .MO3 renamed to .MDZ, or a MO3 packed in another archive? Both seem kind of silly to me, but I've added support for the latter.

  • yam655
  • [*]
foo_dumb
Reply #313
Do the APEv2 tags interfere with any of the modules? I know they wouldn't interfere with Foobar or foo_dumb, but do they interfere with tracking software?

I downloaded ModArchive, and all of the modules (in all formats) are sent as .MOD.zip (where MOD is the normal extension). foo_dumb handles this, of course, but it seems like this would be an easy solution to metadata that would work for multi-song files: Keep one or more additional files in the ZIP file container for the metadata.

Truthfully, this should be a reasonable solution to any file type that doesn't support metadata. Compressing some types of files may be stupid, but even zip -0 (no compression) allows you to move around a group of files as a single file.

It could go so far as to support a "cover.jpg" file within the ZIP that handled the cover image for all songs stored in the archive.

Since any tracking software from the past 10-15 years already supports reading modules from ZIP files directly, this should both allow the data to be stored, as well never risk interfering with other software.

It's just... we already know the APEv2 tags are broken when any module has subsongs. It seems like storing the data as one or more separate files in the ZIP file would be an easy solution.

Cheers,
Steven

  • kode54
  • [*][*][*][*][*]
  • Administrator
foo_dumb
Reply #314
I could also add data storage based around the same core storage mechanism as the official Playback Statistics (foo_playcount) component, and likely reference the tracks by a hash of some sort. I'm not sure exactly what I should hash, though. Perhaps hashing selective portions of the DUMB internal structures read from the module. This shouldn't break metadata linking unless you modify the parts of the song that I hash, or unless I find that some part of a particular format is being read improperly and I change the read behavior, which shouldn't happen often, if at all.

I should note that songs which are inside archives, whether using their original archive file names, or renamed to .MDZ or similar, are not taggable. Nor are MO3 files.

I don't know of any trackers which would barf on the APEv2 tags, but who knows? It is simple footer data appended to the files, and should not cause problems on read by any tracker which ignores data past the end of the file. Of course, they will likely be destroyed when the file is rewritten by the tracker.

  • yam655
  • [*]
foo_dumb
Reply #315
Not taggable inside of archives is a bit of a pain.

I mean, it is super easy to download the whole 35G modarchive and it leaves you will all of the files individually zip'ed unless you go through an unzip them all.

However, the fact that these files actually compress pretty well makes the thought of unzipping them particularly unenticing. While it's just a single command-line to unzip everything, the fact that they'd needlessly take up 40-60% more space just isn't worth it. Space may be cheap, but it isn't free.

My particular use-case is broken for the foo_playcount storage mechanism. For the past 17 years almost every computer I've owned has had two or more of the following: (1) a work account, (2) an administrative account, (3) a play account. (The one I'm using now has all three.) This means any system which both fails to use a real local database (such as MySQL) and fails to write to the files winds up with inaccurate information at best and I totally disregard it at worst.

At this point, I keep foo_playcount installed -- because it is the only way to get any last-played information at all -- but I don't use it at all for ratings, and I periodically bemoan the fact that it is wrong when it comes to the last-played time.

My active playlist is usually some variation of:
(rating EQUAL 3 AND NOT %last_played% DURING LAST 312 WEEKS) OR
(rating EQUAL 4 AND NOT %last_played% DURING LAST 156 WEEKS) OR
(rating EQUAL 5 AND NOT %last_played% DURING LAST 52 WEEKS)

This is my 6y/3y/1y variation. ("MONTHS" and "YEARS" are unsupported.) It should be self-evident that if I don't want to listen to my absolutely favorite music within a year of the last time I played it, I probably get really annoyed when I switch accounts and I hear the same song right a way.

Anyway, that's my foo_playcount gripe. It's actually one of the reasons I periodically look for real alternatives. So far nothing on Windows provides the same functionality as my playlist criteria, and most take a similar storage mechanism approach to rating and recently-played information.

Which is to say: If all the metadata were stored the same way it would be useless to the point I'd ignore it. That's currently the way Miro handles metadata modifications (it doesn't support tag write-back yet). It would also be why I don't listen to music in Miro. (I use it for podcasts and videos.)

I'm okay doing what I originally planned for now. I'll filter out the crap I've downloaded and convert the songs I like to MP3 or OGG files so they can travel easier. (foo_dumb does a great job, but it doesn't help on my Android.) I was already planning to adopt a filesystem structure that included the artist's name to make it easier to find artists I like. I'll just defer tagging until after I start converting.

Cheers,
Steven

foo_dumb
Reply #316
Hello! There is one chiptune, a problem that it, apparently, doesn't go in cycles (or transition at the right time doesn't work, I don't know, look, please) (In MilkyTracker everything is all right). Also at such chiptunes (two and more lines in the work foobar2000 list) it is impossible to write any information in tags. Writes: "Could not update tags (Unsupported file format) of on:"
http://amp.dascene.net/downmod.php?index=632

  • kode54
  • [*][*][*][*][*]
  • Administrator
foo_dumb
Reply #317
Not going in cycles, turn on looping.

Tracks with multiple sub-songs not being taggable is also a known issue.

foo_dumb
Reply #318
Hello, on DUMB 0.9.9.54, when opening certain files, the computer starts to brake strongly (loading of the random access memory skips, many programs drop data from a random access memory on a hard drive, the hard drive works very much, everything hangs up). As a result the track starts to be lost, but somehow and heavy. (On 0.9.9.53 everything it is good) Here an example:
http://www.4shared.com/file/GatE-Lyi/Coma_...s_Djur_014.html?

  • Case
  • [*][*][*][*][*]
  • Developer (Donating)
foo_dumb
Reply #319
Please do not use such horrible file sharing services. Poor kode54 must not be tortured. [ Specified attachment is not available ]
I have no trouble playing this file. Are you sure your computer is OK?

  • kode54
  • [*][*][*][*][*]
  • Administrator
foo_dumb
Reply #320
Thanks for retrieving that for me. That particular file has a problem that was causing my new loader code to allocate somewhere in the range of 2GB of memory, then attempt to read that much from the file, then fail. This was both due to the fact that my code had no safety checks on the instrument and sample header sizes, and also because this file specifies that it has 31 instruments, even though there are only 19, which was causing it to overread. Overread was a problem because I was also allowing APE tags, like the one this file has, to leak into the module reader. Yes, the APE tag will likely trip up any legitimate XM reader in cases of files like this. The older reader would also error out, which would cause it to not read the instrument names for all the short instrument headers.

Everything should work nicely now.

  • yam655
  • [*]
foo_dumb
Reply #321
I have what should be questions that I expect would be common and, well, documented somewhere.

"Expose file info as multi-value tag" -- what tag is used?

I'm periodically setting ApeV2 tags on my modules, but the problem is the file information is only available by the properties dialog -- even though there are ways to modify tags without going through that dialog, I can't seem to get the information I need without it. This would seem to be the answer to that -- if I had any idea as to what tag was actually used.

"Chip-O-Matic" -- what is this? Do I want to use it? Is it generally awesome?

I find this thread to be really horribly verbose when it comes to needing concise answers to basic information about the plugin. :/ I've spent hours (days?) reading, searching and scanning it looking for things that seem to be implicit knowledge and not actually documented anywhere.

Thanks!
Steven Black

  • yam655
  • [*]
foo_dumb
Reply #322
"Expose file info as multi-value tag" -- what tag is used?


I got this resolved. foo_textdisplay and $meta_sep(instrument,$crlf()) and $meta_sep(sample,$crlf())

But I've a new question to add:

Tag caching is mentioned in some of the comments. How do you "force refresh" the tag cache?

Cheers,
Steven Black


  • kode54
  • [*][*][*][*][*]
  • Administrator
foo_dumb
Reply #323
Touch the file modification timestamp, or rename the files. I could add an option to reset the cache, but for now, the only other way is to either close the program, or to overflow its size limit. You could force a cache reset by setting the maximum cache size to 0 and reloading an uncached track.

  • boomman
  • [*]
foo_dumb
Reply #324
Foobar crashes when I drop "tPORt - TuneUp Utilities 2007 6.0.2200crk.XM" file and tells me that problem caused by foo_dumb.
1.1.13, foo_dumb v.0.9.9.55