Messages - parpfish [ switch to compact view ]

Pages: [1] 2 3 4 5 6 ... 8 • next
1
Seedling's Software / Re: Hi Everyone / Random MixTape Maker ideas
« on: February 09, 2009, 08:31 AM »
Hi Seedling

Results from the (still open) Hydrogen Audio 2009 encoding poll

Lossless

FLAC [64.29%]
WavPack [16.22%]
TAK [6.37%]
Monkey's Audio [2.12%]
Apple Lossless [2.51%]

Lossy

MP3 [59.46%]
Ogg Vorbis [13.71%]
AAC (MP4, M4A, AAC) [17.37%]
MPC [4.25%]
WavPack lossy [0.19%]

For context here's a graph of previous results:
http://img206.imageshack.us/img206/3774/ha1fg1.png

By the way it's worth remembering that this is only HA members and though audio enthusiasts they are nor representative of the mass, but perhaps more a sign of future trends. I think the trend is in some ways more significant than the "market share".

Anyway, thought you might find it interesting.

P.

2
Seedling's Software / Re: Hi Everyone / Random MixTape Maker ideas
« on: November 15, 2008, 10:27 PM »
Hi Seedling,

Hope all is well with you. Looks like you've been busy.

Just wondering if there's any chance you can add TAK support to RMTM? In case you don't know, TAK uses APE tags like WavPack.

More about TAK here:
http://www.hydrogenaudio.org/forums/index.php?showtopic=52212
http://www.hydrogenaudio.org/forums/index.php?showtopic=54721

Thanks in advance for your consideration.

Cheers,

P.

ps. Did you get my reply re. HA post a while back?

pps. Any news on dealing with filenames that include an additional fullstop or "period" prior to the extension, e.g. :

filename.something.flac

3
Seedling's Software / Re: feature suggestion
« on: March 26, 2008, 08:34 PM »
if flac files are allowed and the file in question has the extension '.flac' then it checks the standard structure of the file to verify that it is, indeed, a flac file.  i suppose i could save a lot of headaches by eliminating this rigid check and just check extension only, but i don't like that idea.
-seedling (March 23, 2008, 02:19 PM)

Interesting. It's strange, because lossy.flac files are FLAC files, so the "standard structure" of the file is that of a FLAC file. LossyWAV works by rounding bits below the noise floor or outside perceptual hearing to produce a WAV file that the lossless encoders can compress more efficiently. So there shouldn't be anything odd about the actual FLAC file, it's just that the WAV it encoded has more zeros in it than would have been the case if LossyWAV hadn't been used.

Anyway, thanks for considering the ideas, and good luck with getting your system up and running.

P.



4
Seedling's Software / Re: feature suggestion
« on: March 13, 2008, 07:16 PM »
hi seedling

Been using latest build -- very nice and is working really well, so thanks for all your hard work  :Thmbsup:.
I have two suggestions, one I think is pretty minor and probably (at the moment) marginal, the other comes about from using RMTM with a large collection.

Suggestion 1 is a request really, and suggestion 2 is more a thought - something to consider -  more than anything else.

1) Is it possible to add support for lossy.flac files (see here: http://www.hydrogenaudio.org/forums/index.php?showtopic=56129) or really any lossy.wav file compressed with a lossless codec, ie files with the following extensions:

*.lossy.* (i.e. *.lossy.flac; *.lossy.wv; *.lossy.ape; *.lossy.wav)

It looks like the lossyWAV project is going to really take off due to a) transparency b) avoiding transcoding issues from psychoacoustic lossless compression formats (MP3 etc) and c) major reductions in the compression performances of lossless codecs on lossy.wav files.

I tried to add a lossy.flac file to my must have list and it wasn't having any of it - so it looks like RMTM doesn't yet recognise this format (hardly surprising - though I thought it might just look at the last part of the extension i.e. .flac).

My one other suggestion is to do with getting round RMTM's relatively long initial scan time (for large collections) to create a playlist.

It seems to me that there would be 2 possible approaches:

1) The easy (fix) method:
Have an option to load RMTM at startup and allow it to do a low resource/idle time only background scan while in the system tray. So when you choose to run it, it already has scanned the directories and only need to respond to the filters applied. Don't know if that makes sense - or is possible.

2) The nightmare method (in term of work - I would have thought - though don't know)
Use an SQL-Lite database which is refreshed on opening. Thus for collections > 10,000 tracks the processing is relatively fast. But I imagine this would require a re-write? :o   That said, I've been using foobar's foo_custom_info component which reads and writes additional info to an SQL database which is completely outside of foobar's core program. Thus wouldn't it be possible to use a similar method whereby after the scan RMTM writes the gathered info to a SQL DB and then queries that in the future, leaving it for the user to decide when to re-scan and thus refresh the DB of tagged and filename info. Anyway - I'm not technical enough to know if this is feasible or not.

Like I say, just ideas really.

P.






5
Seedling's Software / Re: Mixtape Maker: Updates and Latest Beta Versions Here
« on: February 13, 2008, 08:44 AM »
re: window size:  i just checked my copy and it seems to retain the window size i last have it set to.  i will say that there is a minimum window size set statically to 800 x 600 (for folks who still use this antiquated display size) so you can't make it any smaller than that.  i'm not exactly sure if this is what you're experiencing.  but if you enlarge, stretch, or whatever beyond its minimum size, it should (and does with my copy) retain that window size and position to be restored upon next run.  i suppose i could get rid of the 'minimum size' to allow the form to be shrunk down (if so desired); is this what you're asking for?
-seedling (January 25, 2008, 02:59 PM)

I've worked out what it is:

As you may be able to see from the screenshot, I have a double-width Taskbar (see the chunk of blue below the Start button). Thus RMTM was indeed remembering that its last position was Maximised (res. = 1024 x 768). However it was also (and still is) making an assumption that my Taskbar is single-width. Thus as you can see in the screenshot - the bottom of RMTM is hidden behing the Taskbar and there is headroom at the top -- you can see the other application (foobar) is at the very top of the screen. This is why I couldn't move the window around - as the program believes it is maximised (and in a sense it truly is) it just doesn't look like it; and thus the program is not truly returning to its previous position on last exit. (The Screenshot was taken having closed a Maximised RMTM and then re-opened it --- I should have made that clear).

I hope that explains the problem. Only awkward folk like me (who have double-width taskbars) will experience this problem. Give it a go if you're happy to mess around with your desktop, icons, quicklaunch stuff and you use Win XP.

-parpfish (January 25, 2008, 07:21 PM)

@ seedling -- Did you fix the window maximise with double width taskbar problem above when you did the new redundancy option? Because that problem has gone away. It now opens maximised and takes into account double width taskbar  :)

P.







Pages: [1] 2 3 4 5 6 ... 8 • next
Go to full version