<mrburns>eggggsellent</mrburns>

All of your tracks should be in there, but I'll take a look ... Souping on title is kind of a weird thing since you will very rarely have duplicate titles (probably).

Soups should continue to sync if you rename them (the soupiness is saved in another tag called "soup").

I'll look into the Wendy request.

ms

That's what I mean, as well as .pls files and whatever other sorts of playlist files there might happen to be. This option exists in emplode proper.

The reason is that I have .m3u files in my album folders, which makes it easier to play an album. But that means that on jEmplode directory imports, it creates the album and then a duplicate as a child of that album playlist. Which is annoying.

Plus, I have the feeling that some bogus m3u files might be what caused those errors I saw earlier, which I'm still trying to reproduce, despite my formal rescindment.

mike,

i've been toying with the soups for a few weeks now, and i got a few soupy questions.

#1: i originally created the soups before the "sort by" option was added. when i updated jemplode to a new version, i opted for a "sort" by "tracknumber". i expected all of the soups to be resorted, but they have not. do i need to delete, and then recreate the soup?

#2: if i change sort/tag criteria in the "soup tag" , when do the changes take place? i've changed the search criteria on my soup, and didnt see the soup update. (these were soups on the rio.)

#3: is the sorting only available by one field? (i.e. can i sort by album, then by tracknumber?)

#4 a request: do you think you will be able to implement a "sync" feature that can maintain my computer and rio in sync? i know this feature has been asked for alot in the other forums.

thanks man!
-ted

#1 right now the sort by feature doesn't change the sort of soups ... there are some tricky problems with the way soups work that assume that they are sorted by title ... it's on the list of things-to-do

#2 i don't do much testing with changing the search criteria (as opposed to deleting and recreating). However, what should happen is that you will have to sync to send the new soup setting down to your Empeg, then when it redownloads after the sync, I would _think_ that is when it would be adjusted. Then you'd have to sync again to get the newly added/removed tunes down.

#3 right now you can only sort by one field at a time... this has been requested too, but it's not a really high priority right now... I'll make sure it's on the list though

#4 this has definitely been talked about ... there are a couple ways to do it, and it probably just needs some discussion to decide the best way. I think the best way, albeit the slowest way, is to compare all the hash values of your tunes on your PC and your Empeg and kill or sync ones that don't match. I think you would have to designate one of the locations as the "master" for this process, so you know whether a tune is newly added on one side or freshly deleted on the other.

An alternative way would be to store the original full path to the MP3 in an Empeg tag. The problem here is that while it is very fast to then do the lookup, it breaks terribly if you move your MP3's around at all (i.e. you decide to do artist directories on your PC or something).

Any other ideas for syncing would be appreciated.... How does rsync do it?

Am I the only one experiencing this stuff:

* The tags aren't filling in properly...

I have "Write ID3v2 Tags to Downloaded Files" selected, but the genre and track numbers aren't filling out... I'd LOVE to have the track number use the position fields for population as a lot of my tracks don't have a track number properly populated...

* I'm using "{artist} - {source} - {pos:2} - {title}.mp3" as my filename format, but the POS has mixed results. Sometimes I get no POS at all, sometimes I get a single digit...

I posted this a while ago, but no one said boo...

- Jon

I'll put these on the list...

Heres a presentation on rsync that explains it pretty well. It splits up files and does a MD4 checksum on each piece, then it bundles those up into the signature.

http://olstrans.sourceforge.net/release/OLS2000-rsync/OLS2000-rsync.html

Sean

I just browsed through the RSYNC paper, and if I understand it correctly, it does more than identify if a file has been changed... it tries to locate the change happen, so only the delta needs to be sent (like the unix "diff").

Wouldnt that be overkill for what we want here? we just want to ID if the file has changed, and if so, just overwrite the RIO file. That should be an easier checksum. Perhaps, even the same algorithm that is used now for checking for dups?

-Ted

I think you're right ... Though that rsync paper was really cool to read through In our case, the files are rarely being _modified_, rather they're mostly being added or removed. So we really only need the full-file checksum that we do now. The difference in our case that makes things tricky though is that we lose filename + directory structure on the Empeg side, so we have to _find_ the files on the PC side. One way around this is to keep an index file of computed hash codes at import time, but that's really just as bad as storing the source filename in a tag, since if the file moves or changes name, they'll no longer be in sync. It's just a tricky problem in general.

I tried pre5 and noticed two problems that nobody seems to have mentioned yet.

I can add a folder of songs for uploading just fine. But I am unable to add any single tune for upload.

The other problem involved a failed sync. Everything went a bit funny on me, views were not refreshing and such. So I 'reconnected' to the player and everything came up just fine. The batch of songs that was being uploaded never made it to the player (not even found with refs == 0) but I couldn't re-add them until I disabled duplicate detection.

Perhaps that is not too much to ask for: if you change your directory structure, then the files would have to be recopied.

-t

Any chance we could get upload support for FLAC and Ogg files?

Greg

It's not a very high priority ... since the player can't play them (natively), there's probably not a whole lot of demand right now. I'd need to port a parser for the tags/headers for both of the formats to properly import them, too, which would probably take a little while. However, you should be able to turn on "allow unknown formats" in options and just upload them as non-tune files.

FLAC files just use id3 tags like mp3's so as far as parsing goes, it shouldn't be a real problem. The main thing would be to see the .flac extension and set the codec to "flac". Ogg, on the otherhand, does their own thing on tags for whatever reason. In another project, I just use the file name as the title and artist and set the codec to "ogg".

The reason why I ask all this is just to get the ball rolling. I don't think it'll be long at all before RioPlay starts getting some use, ogg and flac are probably the star attractions to it. Having JEmplode support these at least on a rudimentary level would go a long ways.

Greg

In reply to:

---

FLAC files just use id3 tags like mp3's so as far as parsing goes, it shouldn't be a real problem.

---

Small correction... FLAC uses Vorbis comments now. libFLAC has an interface for getting at them. The format itself is neutral towards id3 tags. The FLAC plugins now read all three (vorbis, id3v1, id3v2) but it's up to each individual app to support them.

Josh

As readers of General know, I'm currently uploading the Harry Potter audio-books.

I tried using jemplode to put the tracks on the player, with some success, but found that the metadata were wrong for these monaural tracks. The length is marked as twice the actual length, and the bitrate is recorded as "vs0" instead of "vm48". I tried with emptool and it also got the length wrong in the same way, and the bitrate wrong in a slightly different way.

The jEmplode upload is the highlit one (blue background) and the emptool one is white background:



For comparison, local tools report:

Title: The Boy Who Lived
Media Type: MPEG 2.0 Layer III
Audio: 49.766888 KB/s, 22KHz (mono)
Length: 10:37

[Edit: it's possible that it's confused by being MPEG 2 Layer 3 and the lower sample rate, rather than by the number of channels]

Some more investigation - I encoded the same track in four different ways: mono 44kHz, stereo 44kHz, mono 22kHz, stereo 22kHz. All four appeared as vs0 in jEmplode, and the last two had the wrong duration.

So the duration bug seems to be related to the use of low sample rates and MPEG 2, and the rate bug appears to be universal.

The MP3 header parsing code is a straight port of emptool's ... I need to talk to dmz and see if his ID3 parser happens to also parse that data too -- maybe I can just use theirs instead.

The bug report I submitted against emptool is probably of use, as it contains a bit of extra research. Basically, emptool always thinks tunes are stereo, and gets the length wrong when it's a 22.05kHz sample-rate. (I didn't try other rates)

You may find some additional useful information about your problem in this thread.

tanstaafl.

Ah, I'd forgotten about that thread, despite being a significant contributor.

Note that the current problem is on the upload side, not the player (in fact, I took to testing this without going as far as synchronising in jEmplode).

But if the player didn't handle MPEG 2.0 until recently, then it's no surprise that the upload tools have problems too. Thanks for the pointer, Doug.