I've got a few very short audio clips (less than a second long) to be played on various events (button hover, click, etc). However, there is usually a significant lag between the action and the actual playing of the sound. I have tried both embedding the sound in the .swf, and loading it externally at the start, but both lead to the same results. Likewise, I've tried with compressed and uncompressed audio.
Download ⚡ https://t.co/GypXWjVszS
What it seems like is that the audio buffers are just a lot longer than I need them to be, like perhaps Flash is optimized more towards playing longer sounds without any stutter at the expense of a little more latency in starting sounds. Could this be it? Is there any way to change them? Since what I'm working on will never need to play sounds more than a second or so long and will always be loaded completely at the start, it wouldn't hurt it at all to have really short buffers.
One other possible thing that might be the cause: if I use .wav files when using loadSound()... I can't get it to actually play the sounds. There's no errors, and everything returns as it should, but no actual sound is played, which is why I have them as .mp3 currently. Perhaps when using .mp3 audio (or any compressed audio), there just will be lag in decoding it? The reason I still have doubts about this, though, is that when embedding them in the .swf as .wav files (by importing them into the library), they still have the same latency on playback.
The sound files are tiny, less than 10kb generally. The lag is apparent enough that one of the first complaints someone had when looking at it was that the sound effects on button hovers seemed delayed, so it wasn't just me being picky. I feel like I must just be doing something wrong; there's too many flash things out there that have snappy sound effects without anywhere near this kind of lag.
edit: In response to the first response about sound files themselves, I've already checked, and the sound starts immediately at the start of the file (even clipping out everything but the very first millisecond of sound, I can still hear the start of the 'tick' noise it makes).
There is no need for a loop look up since that is what the hash table is for. Also, you shouldn't use an Array at all for that since an Array is an ordered set which is indexed using integers. You want to use an Object (or Dictionary) in this case and name it soundMap (since it maps sound names to sound objects).
As for sound latency -- there should be none. I've done quite a bit of sound in Flash (including tons of one off rollover and rollout sounds) and it has never been an issue. However Flash Player 10 has a new low-level sound API which is described by one of the Adobe engineers in that article. A solution involving that is a bit of a sledge hammer but perhaps you are looking for millisecond accuracy.
The advice fenomas gives is wise: check the mp3 file for deadspace at the start and end and trim it as close as possible. Also - what is the path from the event handler to your play statement? Are there any possible blocks there? What is the format of the mp3? Flash works best with specific encodings (44.1 hHz and 128 bit I believe).
Well, my first-blush answer is that when I've done things like this, normally I find that sound files have a certain amount of lead time built in. You could check in a sound editor, but What I've done in the past is to import the sound into the Flash IDE, make an empty movie clip, and put the sound on frame 1 of the clip. Then, but editing the frame sound you get a nice little interface to drag the start/end points of the sound playback. Then I used to either attach/remove the clip to play the sound, or leave it somewhere and use frame commands.
I've always wanted to clean up my music filenames and metadata (any missing or inconsistencies), and I recently found MP3tag and Musicbrainz Picard which I now love. I selected all my songs in iTunes (so they come from iTunes Media Music Folder), and drag/drop them into a new giant folder "B". Using both those 2 software, I got updated metadata (any missing, or compared some existing: albums, artwork, genres, dates, etc), deleted unnecessary/random metadata tags (usually on
Now back to iTunes. I went into the iTunes Media (Music) Folder and deleted ALL of those Artist/Album sub-folders which contained all the old non-updated music files. Made that folder empty. Then I copied all my updated music files from folder B and pasted them directly into that iTunes Media (Music) Folder with NO sub-folders. (I purposefully did NOT drag/drop to iTunes first b/c that would create duplicates of everything).
I had a similar problem long ago, but iTunes was able to Locate/Find all, or large batches, of music files all at once, so it was a quick fix and not really an issue. However this time, it will only locate 1 file at a time...
How can I locate ALL (or large batches at a time - not 1 by 1) missing file links in iTunes? I'd highly prefer this so I can keep all of my existing playlists, play counts, etc, but it'd take a very long time doing it 1 by 1. If it would help, I don't mind "consolidating" my library if that puts the files back into Artist/Album sub-folders (within iTunes folder) making it easy to "Locate", but I do NOT want their filenames changed.
Other issue I just found - I noticed when I do Locate and "re-link" a song in iTunes, it does seem to correctly replace old metadata with new metadata in iTunes (great!), but for any metadata/tag I've cleared (made blank/empty) on the file itself, it doesn't replace/clear any existing/old data in iTunes. I want it blank there too, and hopefully not write that old data back onto the file in iTunes Media (Music) Folder. I guess I can go through and clear it in iTunes also... or any better way?
I gather you've found my Windows FindTracks script, which can be useful for reconnecting broken links in the library. It works best however when the tracks are in the more typical layout of artist and album folders. Locating a specific file from 3,000 in a single folder is tough. My large library has around 65k tracks which would be impossible to scan using your - layout.
If you look at this post it sets out some of the search patterns the script tries. I can potentially add an option to the script so that it works better with your layout. Another option would be to add the files from their current location and then use my deduping script (see Duplicate songs in iTunes - Apple Community) to dedupe while preserving playlist membership, ratings, playcounts, etc. and eliminating the broken links. Once the library is working again correctly in iTunes we can discuss how to set out the files the way that you want them without breaking the links to the library (e.g. use CustomRenamer). You could also turn off the option that copies files to the media folder when you add to the library.
Try downloading the new version of the FindTracks script now. I've tweaked the matching script such that it works in a test here. It's already using a fuzzy matching scheme which copes with case differences and certain minor changes of spelling.
At this point the script is actually looking at the correct file for the current track, but looking for the standard iTunes filename for it, so the fuzzy matching mechanism doesn't see them as a match.
The expected path when things cannot be found is always the standard iTunes path [\Music]\\\[D-]## .. It doesn't indicate the alternate patterns that have been tried. The top left image in your Test 2 shows the script looking through potential folders that exist and conform to part of the standard pattern. A key here is that it looks in each of them, you don't need to manually add subfolders, but from the point of view of testing it helps to work with a folder that has tens of files rather than thousands.
Let us dig in a little deeper. Please right-click > Save link as ExportImportCustom which is a custom version of my ExportImport script and produces output like this:
So I can see all of the values that should be relevant (artist, name, iTunes file size, actual file size, actual filename) all at the same time. I can see the exact file sizes match for here, along with the predicted filenames when using the - pattern.
Here is another test where I've downloaded fresh versions of these tracks using standard iTunes names, saved the .itl file, used my CustomRenamer script to move them into \Music\ - format, restored the saved .itl file so it sees all the tracks as missing, and then used FindTracks to fix them.
Thanks for those details. This is a table showing the file size differences between the entry in the library, and the target file. Currently the script is set up to match only when the difference is less than 15,000 bytes. This explains the pattern of successful and unsuccessful matches in the data that you sent me.
Which should result in more automatic matches, and the occasional prompt for really large differences. You can choose a larger value for Limit if desired, or set to 0 to ignore any difference in file size altogether.
Next I took copies of 1 random song, the Alabama song, and the Thomas Rhett song it mismatches with and put them in a separate folder. Ran script manual mode on that folder only, 500,000 size limit, Moreinfo on, with similar results. Still matching with the Thomas Rhett song.
I appreciate your help thus far, as the FindTracks script manual mode is still faster and much less tedious than iTunes 1 by 1, then I could manually connect any remaining. That'd still keep my playlists/etc unlike starting a new library, adding all updating songs, and having to re-create all playlists/etc. I don't want to take too much of your time on this. It's up to you if you want to investigate further, depending on how likely or difficult a solution may be. Idk if disabling Pass=3 and keep Pass=3.1 would be enough to prevent any mismatch so I could use auto mode, or if another possible approach/solution might work.
795a8134c1